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Dennis Ritchie, legendary 
developer of the UNIX Operating 
System, puts it very simply: “The 
reason the original UNIX operating 
system was so small and elegant was 
because we did things that we really 
wanted to do.”* 

Although conventional UNIX has 
grown (literally) beyond Ritchie’s 
original vision, many people still look 
to this classic OS to do what they 
want to do. 

But not if they want realtime 
performance. UNIX has unequalled 
power as a development tool, but you 
can forget about running realtime apps 
on conventional UNIX systems. They’re 
simply too big and too slow. 

Until now. 

Presenting QNX 4.0. The UNIX 
system that’s responsive enough for 
realtime apps, small enough for PC 
platforms, flexible enough for transpar¬ 
ent networking, and modular enough 
for the most demanding configurations. 

POSIX Means Portable 

UNIX systems come in more 
flavors than ice cream. Which is why 
IEEE’s POSIX standard is now such an 
important safeguard of portability. 


At Quantum, we’re committed 
to the POSIX standard, and we’ve 
rewritten QNX to give developers a 
standard OS interface they can 
depend on. As a result, QNX is now 
a true UNIX operating system—but 
not a conventional one. 

Performance At Run Time, 
Design Time, All The Time 

Only QNX combines the perfor¬ 
mance of a dedicated realtime 
executive with the time-saving 
benefits of a rich UNIX development 
environment—including a host of 
utilities, an award-winning C compiler, 
and an optional OPEN LOOK™ GUI 
package. 

QNX is Distributed 

The QNX operating system lets 
you extend the limits of any one 
microprocessor. Whether you’re 


running a network of four or 400 
machines, QNX makes it all feel like a 
single computer. 

Interprocess communication is 
network-wide, so every process can 
transparently access every resource— 
programs, files, devices, even CPUs— 
anywhere on the network. And you 
can set up your network using any mix 
of Intel-based PCs. 

Responsive Tech Support 

Only QNX’s support hotline can 
put you in direct contact with the 
Technical Development team itself. 
And you’ll have access to our 24-hour 
online conferencing and update 
system, where the response time to 
your questions is almost like real time. 

“If Only...” 

Wherever computers do serious 
work for serious people, the UNIX 
operating system has made possible a 
lot of the “things we wanted to do.” 
But people who want realtime 
solutions have been waiting a 
long time to share in the benefits. 

A The wait is over. 



’ 


What UNIX was meant to be. 

For more information, please phone (613) 591-0931. 


Quantum Software Systems Ltd. ■ 175 Terrence Matthews Crescent * Kanata, Ontario, Canada ■ K2M 1W8 


‘“Who is the Real Dennis Ritchie?" UNIXWORLD, January 1991, p. 46. 

QNX is a registered trademark and QNX Windows is a trademark of Quantum Software Systems Ltd. UNIX is a registered trademark and OPEN LOOK is a trademark of AT&T. 


Reader Service Number: 
















NEW OBJECT-ORIENTED LANGUAGE 



After you’ve tried new MODSIM II 
other object-oriented languages will seem primitive 

Free trial and, if you act now, free training 


M ODSIM II is a modern 

high-level, object-oriented 
language with these important 
benefits: 

• Object-oriented programming. 

The powerful mechanisms that 
help you develop structured, 
easily maintainable code. 

• A compact, readable language. 
Your programs are at least 25% 
smaller than equivalent C + + 
programs and they are easier to 
read. 

• Symbolic debugger. Error detec¬ 
tion and correction are simplified 
through steptracing, multiple 
breakpoints, and data viewing. 

• Graphics and animation. You 
easily lay out your graphical in¬ 
terface with no programming. 

• Standardization across com¬ 
puters. Your development invest¬ 
ment is preserved when you 
change computer types. 

• Simulation. All the features you 
need to do simulation and auto¬ 
matically collect statistics are 
available if you need them. 

With these benefits, the time and 
cost you need to develop programs is 
sharply reduced. 


Free trial offer 

The free trial contains everything 
you need to try MODSIM II on your 
computer. Try the language, the 
quality and the timeliness of our sup¬ 
port, and our documentation and 
training— everything you need for a 
successful project. 

We’ve been providing software 
and support for 29 years-we’ll be 
here when you need us. 

Computers with MODSIM II 

MODSIM II® is available for all 
popular computers. 

Charter User Group benefits 

CACI is now organizing a MOD¬ 
SIM II Charter User Group. Mem¬ 
bers receive a reduced price, early 
releases, and other benefits. 

For a limited time we also include 
free training. Call today to avoid 
disappointment-class size is limited. 

For immediate information 

In the US, call Hal Duncan at (619) 
457-9681, or Fax (619) 457-1184. In 
Canada, call Peter Holt on (613) 
782-2474, Fax (613) 782-2202. In 
Europe, call Nigel McNamara, in the 
UK, on 044 276 671 671, Fax 044 276 
670 677. 


Rush information on 
MODSIM II. 

□ Yes, I want to learn the reasons for 
the growing popularity of MODSIM II. 

Charter User Group offer-return the 
coupon today and we will include a 
free course worth $950. 


□ Send details on your University Offer 

Return to: Mie comp 

CACI Products Company 
3344 North Torrey Pines Court 
La Jolla, California 92037 

Call Hal Duncan at (619) 457-9681 
Fa* (619) 457-1184 


In Canada: 

CACI Products Division 
200-440 Laurier Avenue West 
Ottawa, Ontario KIR 7X6 

Call Peter Holt on (613) 782-2474 
Fax (613) 782-2202 


In Europe: 

CACI Products Division 
Suite 11, Coliseum Business Centre 
Watchmoor Park, Riverside Way 
Camberley, Surrey GU15 3YL, UK 

Call Nigel McNamara on 044 276 671 671 
Fax 044 276 670 677 
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A hierarchy of questions and answers about the features of distributed computing systems leads to an overall system 
description and facilitates system comparisons. 

28 Logical Time in Distributed Computing Systems 
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Partially ordered logical clocks can provide a decentralized definition of time for distributed computing systems, 
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Kyu S. Park, and Hirohiko Nakano 

Analyzing why existing distributed systems are limited, the Galaxy research project borrows many concepts and 
proposed facilities and integrates them with its own novel design features. 

42 Tools for Distributed Application Management 

Keith Marzullo, Robert Cooper, Mark D. Wood, and Kenneth P. Birman 
Distributed computing, like anything else, profits from good management. Here, we discuss the issues of managing 
distributed applications and present a set of tools that solves some long-standing problems. 
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Bill Nitzberg and Virginia Lo 
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Communication Facilities for Distributed Transaction-Processing Systems 
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Communication software is critical in distributed computing systems. This research identifies efficient mechanisms 
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ADVANCE ANNOUNCEMENT 



Conference on 

Software Maintenance 
1991 

Sorrento, Italy • October 14-17, 1991 


Conference Committee 


Theme: Software Maintenance—International Perspective 


General Co-Chairs 
John Munson 

Division of Computer Science 
University of West Florida 
Pensacola, FL 32514 
Phone: (904)474-2989 

Roberto Ciampoli 
Olivetti Information Services 
Vie Croce 19, 00142 Rome, Italy 
Phone: +39 (6) 5411552 
Fax: +39 (6) 5415239 

Immediate Past Chair 

Thomas M. Pigoski 
Technical Software Services, Inc. 

P.O. Box 4796 
Pensacola, FL 32507 
Phone: (904)934-0164 

Program Co-Chairs 
Malcolm Munro 

Centre for Software Maintenance 
University of Durham 
Durham DH1 3LE, England 
Phone: +44 (091) 374-2634 
E-mail: malcolm.munro@uk.ac.durham 

Vaclav Rajlich 

Department of Computer Science 
Wayne State University 
Detroit, MI 48202 
Phone:(313)577-5423 
E-mail: vtr@cs.wayne.edu 

Program Committee 

Robert S. Arnold (USA) 

Paolo Benedusi (Italy) 

Bruce Blum (USA) 

Frank Callis (USA) 

Ned Chapin (USA) 

Ugo De Carlini (Italy) 

Richard Donnelly (USA) 

Mari Georges (France) 

Mary Jean Harrold (USA) 

Takis Katsoulakos (UK) 

Taghi Khoshgoftaar (USA) 

Kouichi Kishida (Japan) 

Pasi Kuvaja (Finland) 

Paul Layzel (UK) 

Loredana Mancini (Italy) 

Isao Miyamoto (USA) 

Norman Schneidewind (USA) 

Harry M. Sneed (Germany) 

Nicholoas Zvegintzov (USA) 


Tutorials: 

• Applying Software Measures Effectively by David N. Card 

• Software Repository and Bridge Technology by Robert S. Arnold 

• Software Maintenance Technology by Nicholas Zvegintzov 

• Software metrics by Horst K. Zuse 

Keynote Address: 

Manny Lehman: What Do We Maintain When We Maintain Software? 
Tom McCabe: Redevelopment Tools—Quality Assurance 

Technical Sessions: 

• Management of Maintenance 

• Reverse Engineering and Reengineering 

• Software Measurement 

• Code Analysis 

• Maintenance of Object Oriented Programs 

• Testing and Slicing 

• Environments for Maintenance 

• Improving Maintenance 

• Experience Reports 

Panel Discussions: 

• Software Certification 

• Software Maintenance and Reverse Engineering 

• Software Maintenance in Japan 

• Software Maintenance in Europe 

• Software Maintenance in U.S.A. 


About Sorrento ... 

Sorrento is located on the east coast of Italy, approximately 50 KM south and 
west of Naples. The city of Sorrento is located on the Bay of Naples. A short 
distance away by boat is the resort island of Capri. In the east, Mount 
Vesuvius creates an impressive backdrop. Tours are available to the lost (and 
found) city of Pompei. 


Sponsors: 


❖ 

IEEE 


IEEE Computer Society— 
Technical Committee on 
Software Engineering 

IEEE 


With corporate support from: 


OiS* 


In cooperation with: 

(SM$) 


_ Software Maintenance Association 
acm Association for Computing Machinery 


S3 


Consorzio Campano di Ricerca per 
L'lnformatica e L'Automazione Industriale 


Software Maintenance Study Group, Tokyo 











Award winning CASE tool 
selected by the experts 

TM 

TurboCASE 3.0 


• For the Macintosh. 

• Structured Analysis (with 
Real-Time extensions). 

• Data Modeling. 

• Object Oriented Analysis. 


• Structured Design. 

• Object Oriented Design (3rd Q, 91) 

• 3rd Party Code Generator (2nd Q, 91) 

• 3rd Party Bridges to CDIF & Teamwork® 
by Cadre Technologies. 


TurboCASE is one of the award winners of the 1990 Productivity 
Awards presented by Computer Language Magazine on Feburary 
12,1991. TurboCASE is the only Macintosh product selected in 
the CASE tools catagory for it's significant impact on improving 
the way software products are developed. 


wvmruicn 

LANGUAGE 




StructSoft, Inc. 5416156th Ave. SE, Bellevue, WA 98006. 
Tel: 206-644-9834 Fax: 206-644-7714 
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Treasurer’s MESSAGE 


1990 financial results 



Following this report are the Coopers 
& Lybrand audited financial state¬ 
ments for 1990. The final figures show 
an operating deficit of $170,600 but an 
overall surplus of $115,200. The sur¬ 
plus was the result of a one-time in¬ 
come of $285,000 received as a result 
of the dissolution of AFIPS (Ameri¬ 
can Federation of Information Pro¬ 
cessing Societies). 

While an operating deficit is of con¬ 
cern, it is relatively small, represent¬ 
ing only 0.56 percent of total 1990 ex¬ 
penditures. However, the society’s net 
worth of $2.8 million consists primari¬ 
ly of fixed assets (plant and equip¬ 
ment); as a result, even small deficits 
strain liquidity. 

The severe liquid reserves problems 
anticipated last year were avoided by 
prompt action of the Board of Gover¬ 
nors in mid-year. In addition, the 


board adopted new budget policies 
that will lead to the rebuilding of our 
liquid reserves over the next several 
years. 

Many factors, including the reces¬ 
sion, the war in the Persian Gulf, and 
a general decline in the computer in¬ 
dustry, contributed to the loss of in¬ 
come. For example, cuts in corporate 
travel expenditures have affected our 
conference income. 

In the face of declining income in 
most society programs, the board took 
steps to control expenses. These ef¬ 
forts will continue even while the 
Computer Society increases important 
services to its membership. In 1992, 
for example, a new magazine. Annals 
of the History of Computing, will 
make its debut. Both the Transactions 
on Parallel and Distributed Systems 
and the Transactions on Knowledge 


and Data Engineering will move from 
quarterly to bimonthly publication. 

Figures 1 and 2 reveal interesting 
facts about the society. We have bal¬ 
anced, diverse sources of income and 
are not overly dependent on any one 
source of income. The majority of the 
society’s funds go directly into member 
services and the organization required 
to support those services. Staff salaries, 
benefits, and other overhead expendi¬ 
tures remain somewhat smaller than is 
typical for similar organizations. 

The Computer Society’s volunteer 
and staff leaders are carefully moni¬ 
toring expenses to ensure that we con¬ 
tinue to provide valuable services to 
our members while remaining a finan¬ 
cially healthy organization. 

Joseph Boykin, Treasurer 

IEEE Computer Society 



Figure 1. Computer Society income structure; 1990 total Figure 2. Computer Society expense structure; 1990 to- 
income, $20.4 million. tal expenses, $20.2 million. 


COMPUTER 









Report of independent accountants 


IEEE Computer Society Balance Sheets 
December 31,1990 and 1989 


Assets 

1990 

1989 

Current assets: 



Cash, including interest-bearing accounts 

$ 195,300 

$ 163,600 

Investments (Note 3) 

1,116,500 

1,897,100 

Accounts receivable, less allowance 



for doubtful accounts of $79,600 in 1990 



and $66,400 in 1989 (Note 9) 

1,647,100 

1,079,100 

Receivable from Institute of Electrical 



and Electronics Engineers, Inc. (Note 7) 

252,200 

119,600 

Conference receivables 

443,800 

485,200 

Conference advances 

266,600 

322,600 

Inventory (Note 2) 

887,200 

657,800 

Prepaid expenses and other assets 

497,000 

674,900 

Total current assets 

5,305,700 

5,399,900 

Fixed assets, net (Notes 2, 4 and 5) 

3,682,500 

3,722,200 

Total assets 

$8,988,200 

$9,122,100 

Liabilities and fund balances 



Current liabilities: 



Demand note payable to bank (Note 5) 

$ - 

$ 343,100 

Current portion of long-term debt (Note 5) 

79,700 

1,182,700 

Accounts payable and accrued expenses 

1,387,400 

1,411,500 

Deferred income: 



Membership fees and subscriptions 

3,138,900 

3,234,700 

Conferences 

15,300 

27,600 

Advertising and other 

107,200 

132,300 

Total current liabilities 

4,728,500 

6,331,900 

Long-term debt, less current portion (Note 5) 

1,451,300 

97,000 

Total liabilities 

6,179,800 

6,428,900 

Fund balances: 



Undesignated 

2,703,400 

2,468,000 

Designated, primarily for technical 



committees (Note 8) 

105,000 

225,200 

Total fund balances 

2,808,400 

2,693,200 

Total liabilities and fund balances 

$8,988,200 

$9,122,100 


Board of Governors of the 
IEEE Computer Society: 

We have audited the accompanying 
balance sheets of the IEEE Computer 
Society (the society) as of December 
31,1990 and 1989, and the related 
statements of revenue, expenses, and 
changes in fund balances for the years 
then ended. These financial state¬ 
ments are the responsibility of the so¬ 
ciety’s management. Our responsibili¬ 
ty is to express an opinion on these 
financial statements based on our au¬ 
dits. 

We conducted our audits in accor¬ 
dance with generally accepted audit¬ 
ing standards. Those standards re¬ 
quire that we plan and perform the 
audit to obtain reasonable assurance 
about whether the financial state¬ 
ments are free of material misstate¬ 
ment. An audit includes examining, 
on a test basis, evidence supporting 
the amounts and disclosures in the fi¬ 
nancial statements. An audit also in¬ 
cludes assessing the accounting princi¬ 
ples used and significant estimates 
made by management, as well as eval¬ 
uating the overall financial statement 
presentation. We believe that our au¬ 
dits provide a reasonable basis for our 
opinion. 

In our opinion, the financial state¬ 
ments referred to above present fairly, 
in all material respects, the financial 
position of the IEEE Computer Soci¬ 
ety as of December 31, 1990 and 1989, 
and the results of its operations for 
the years then ended, in conformity 
with generally accepted accounting 
principles. 

Coopers & Lybrand 

Washington, D.C. 

April 3,1991 

Notes to financial 
statements 

1. Organization and purpose 

The IEEE Computer Society (the 
society) is organized within the Insti¬ 
tute of Electrical and Electronics En¬ 
gineers, Inc. (IEEE), an organization 
exempt from income tax, pursuant to 
Internal Revenue Code Section 
501(c)(6). Within the bylaws of IEEE, 
delegation of the responsibility for the 
society’s operations has been placed 


with the society’s Board of Governors 
and Executive Committee. The soci¬ 
ety’s constitution states that “The so¬ 
ciety shall be scientific, literary, and 
educational in character. The society 
shall strive to advance the theory, 
practice, and application of computer 


and information processing science 
and technology and shall maintain a 
high professional standing among its 
members. The society shall promote 
cooperation and exchange of technical 
information among its members and 
to this end shall hold meetings for the 
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IEEE Computer Society 

Statements of Revenue, Expenses and Changes in Fund Balances 
for the years ended December 31,1990 and 1989 



1990 

1989 

Revenue: 

Computer Society membership fees 
Periodical subscriptions and 

$ 1,531,200 

$ 1,256,000 

other publication activities 

Conventions, conferences and 

11,732,000 

10,568,700 

other technical activities 

6,322,700 

4,895,800 

Interest income (Note 3) 

100,100 

127,800 

Other income (Note 9) 

581.300 

277.200 

Total revenue 

20.267.300 

17,125,500 

Expenses: 

Periodical and publication activities 
Conventions, conferences and 

10,727,436 

10,063,900 

other technical activities 

5,515,764 

3,963,300 

Administration 

3,908,900 

3,416,400 

Total expenses 

20,152,100 

17,443,600 

Excess of revenue over (under) expenses 115,200 

(318,100) 

Fund balances at beginning of year 

2,693,200 

3.011.300 

Fund balances at end of year 

$ 2,808,400 

$ 2,693,200 


presentation and discussion of techni¬ 
cal papers; shall publish technical 
journals; and shall, through its organi¬ 
zation and other appropriate means, 
provide for the needs of its members.” 

2. Summary of significant accounting 
policies 

Reporting entity 

The accompanying financial state¬ 
ments include all society accounts 
maintained at the society’s offices in 
Washington, DC; Los Alamitos, Cali¬ 
fornia; Brussels, Belgium; Tokyo, Ja¬ 
pan; and certain accounts maintained 
at IEEE Headquarters. The accompa¬ 
nying financial statements do not in¬ 
clude the accounts of society chapters 
which operate directly under IEEE. 

Income recognition 

Income from annual membership 
fees and periodical subscriptions is 
recognized during the year to which it 
pertains. The society’s share of reve¬ 
nue and expenses for conferences par¬ 
tially or entirely sponsored by the so¬ 
ciety is generally recognized in the 
year in which the conference is held. 


Functional allocation of expenses 

The costs of various society activi¬ 
ties have been accounted for on a 
functional basis in the statements of 
revenue, expenses and changes in 
fund balances. Accordingly, certain 
costs have been allocated among the 
various activities and administration. 

Inventory 

Inventory consists of tutorial books 
and standards published by the soci¬ 
ety and is stated at the lower of cost 
or net realizable value. Cost is deter¬ 
mined on an average cost basis. 

Fixed assets and depreciation 

Fixed assets are recorded at cost 
when purchased. The society provides 
for depreciation of fixed assets by 
charges to expense at rates considered 
adequate to amortize the cost of such 
assets over their estimated useful lives 
(5 to 10 years for office furniture and 
equipment; 30 and 35 years for build¬ 
ings) on a straight-line basis. 

When fixed assets are retired or 
otherwise disposed of, the property 
and accumulated depreciation ac¬ 
counts are reduced by the applicable 


amounts and any gain or loss is re¬ 
flected in income. 

Reclassifications 

Certain 1989 amounts have been re¬ 
classified to conform with the 1990 
presentation. 

3. Investments 

Investments, which are stated at 
cost, consist of unrestricted deposits 
with IEEE and bear interest based on 
the average monthly balance main¬ 
tained by the society. 

4. Fixed assets 

Fixed assets as of December 31 are 
shown in Table 1. 

Depreciation expense was $299,500 
and $290,500 in 1990 and 1989, respec¬ 
tively. 

5. Notes payable 

Notes payable as of December 31 
are shown in Table 2. 

During 1990, the society consolidat¬ 
ed its existing mortgage loan and de¬ 
mand note into a single note payable. 
The note is collateralized by a first lien 
deed of trust on the Washington, DC, 
property. Principal is to be paid month¬ 
ly in graduated amounts, together with 
interest, through the term of the note, 
with the remaining principal balance 
due on September 21,1997. 

The note payable, due September 
25,1992, is collateralized by certain 
equipment which was purchased with 
the proceeds of the note. Repayment 
is made in equal monthly principal in¬ 
stallments of $4,616, plus interest, 
with the remaining balance payable 
on September 25,1992. 

Interest expense relating to all of the 
above notes amounted to $151,600 and 
$183,800 in 1990 and 1989, respectively. 

In September 1988, the society en¬ 
tered into a working capital loan 
agreement, which provides for a maxi¬ 
mum borrowing of $300,000 at the 
bank’s floating prime rate. At Decem¬ 
ber 31,1990 and 1989, there were no 
borrowings outstanding under this 
line of credit. 

Annual maturities of long-term 
debt outstanding as of December 31, 
1990 are as follows: 

1991 $ 79,700 

1992 68,400 

1993 29,600 

1994 32,700 

1995 36,100 

Thereafter 1,284,500 

Total $1,531,000 
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6. Pension plan 

The society participates in a de- 
fined-benefit pension plan sponsored 
by IEEE. The IEEE plan covers sub¬ 
stantially all IEEE employees, includ¬ 
ing those of the society. It is the policy 
of IEEE to fund pension costs ac¬ 
crued. 

Statement of Financial Accounting 
Standards (SFAS) No. 87, “Employers 
Accounting for Pensions,” requires 
that certain disclosures be made of the 
actuarial present value of benefit obli¬ 
gations, the projected benefit obliga¬ 
tion, the fair value of the available 
plan assets, and the accrued pension 
costs. Such disclosures are not pre¬ 
sented for the society because the 
structure of the IEEE plan does not 
readily permit the plan’s assets and 
benefit obligation data to be deter¬ 
mined for each individual society. 
Based upon actuarial valuations of the 
IEEE plan, assuming a discount rate 
and an expected long-term rate of re¬ 
turn on assets of 7.75 percent and 8.25 
percent in 1990 and 1989, respectively, 
and an increase in the level of com¬ 
pensation of 5.25 percent and 5.75 
percent in 1990 and 1989, respectively, 
the IEEE plan assets exceeded the 
projected benefit obligation at De¬ 
cember 31,1990 and 1989. The 
IEEE’s funding policy is to contribute 
amounts at least equal to the mini¬ 
mum funding requirements of the 
Employee Retirement Income Securi¬ 
ty Act of 1984 (ERISA) and limits 
such contributions to amounts no 
greater than those computed under 
the full-funding limitations of the In¬ 
ternal Revenue Code. Based on such 
limitation, no contributions were 
made to the plan in 1990 and 1989. In 
addition, the society was allocated 
$38,000 of pension expense in 1990 
and no pension expense in 1989. 

7. Related-party transactions 

Certain general and administrative 
expenses incurred by IEEE Headquar¬ 
ters and charged to the society amount¬ 
ed to $1,043,400 in 1990 and $1,015,100 
in 1989. In addition, the society sells 
published materials to IEEE. Such 
sales amounted to $393,700 in 1990 and 
$305,300 in 1989. Other transactions 
undertaken in the normal course of 
business between the society and IEEE 
have been reflected in the society’s fi¬ 
nancial statements. 

8. Designated fund balance 

The Board of Governors of the so¬ 
ciety has designated a portion of sur- 


Table 1. Fixed assets as of December 31. 



1990 

1989 

Land 

$ 1,334,400 

$ 1,334,400 

Buildings and improvements 

1,995,700 

2,008,400 

Office furniture and equipment 

1,409,500 

1,384,900 


4,739,600 

4,727,700 

Accumulated depreciation 

(1,057,100) 

(1,005,500) 


$ 3,682,500 

$ 3,722,200 


Table 2. Notes payable as of December 31. 



Annual 




interest rate 

1990 

1989 

Note payable. 

Prime 



balance due on September 21,1997 

+ 0.15% 

$1,434,000 

$1,127,300 

Demand note payable, 




balance due on May 1,1990 

10.5% 


343,100 

Note payable, 




balance due on September 25,1992 

9.5% 

97,000 

152,400 



1,531,000 

1,622,800 

Less: Amount due within one year 


79,700 

1,525,800 



$1,451,300 

$ 97,000 






plus funds received from conferences 
for use by technical committees. As of 
December 31,1990, the Board has 
designated a maximum of $105,000 
from conference surpluses to be avail¬ 
able for technical committee use dur¬ 
ing 1991. At the end of 1991, all re¬ 
maining technical committee 
surpluses will revert to undesignated 
fund balances. 

9. Other income 

During 1990, the American Federa¬ 
tion of Information Processing Societ¬ 
ies (AFIPS), of which the society was 
a member, was dissolved. According¬ 
ly, the society has recognized 
$286,000 as income in 1990, which 
represents the society’s portion of 
funds to be distributed to former 
members. This amount is included in 
accounts receivable at December 30, 
1990. 


10. Lease commitments 

The society leases certain office 
space and equipment under long-term 
leases. Certain leases contain renewal 
provisions or may require payment of 
taxes, maintenance, and repair costs. 
Future minimum rental payments un¬ 
der leases having initial or remaining 
lease terms in excess of one year are 
as follows: 

1991 $152,000 

1992 126,000 

1993 100,000 

1994 100,000 

1995 78,000 

Total $556,000 

Rent expense was $93,000 and 
$57,000 for the years ended December 
31,1990 and 1989, respectively. 
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utomated teller machine networks, airline reservation systems, and on¬ 



site validation of credit cards provide three examples of the pervasive- 


-*■ JL ness of distributed systems in everyday life. In their professional lives, 
scientists and researchers rely heavily on distributed systems for electronic mail, 
remote login, network file systems, page swapping, and remote file transfer. The 
Internet electronic mail system, for example, is one of the most useful pieces of 
scientific infrastructure developed in the past 10 years. 

Basically, a distributed computing system consists of a collection of autonomous 
computers connected by a communication network. The sites typically do not 
share memory, and communication is solely by means of message passing. Over the 
past two decades, the availability of fast, inexpensive processors and advances in 
communication technology have made distributed computing an attractive means 
of information processing. 

As early as 1978, Enslow 1 specified five properties for defining a distributed 
computing system: 

• multiplicity of general-purpose resource components, both physical and logi¬ 
cal, that can be dynamically assigned to specific tasks; 

•physical distribution of the physical and logical resources by means of a 
communications network; 

• a high-level operating system that unifies and integrates control of the distrib¬ 
uted components; 

• system transparency, which allows services to be requested by name only; and 

• cooperative autonomy, characterizing the operation and interaction of both 
physical and logical resources. 

The many practical motivations for distributed systems include higher perfor¬ 
mance or throughput, increased reliability, and improved access to data over a 
geographically dispersed area. 2 However, pursuing these potential advantages has 
exposed a broad set of new problems. Ironically, attempts to exploit a feature often 
degrade that very feature. For example, improving reliability through redundancy 
immediately requires recovery mechanisms, which can themselves become a 
serious source of potential failure and reduce overall system reliability. 

During the last two decades, a number of subfields have become well estab¬ 
lished. Increasing interest in these subfields, not all of which could be included, 
provided the impetus for this special issue of Computer (see “Further reading” 
sidebar, p. 12). Cutting across the subfields are two camps of researchers who see 
their motivations differently: one camp views distribution as a means to an end; the 
other views it as imposed by the situation. 
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In the first case, distribution of re¬ 
sources is seen as a way to achieve some 
goal such as 

• massively parallel, general-purpose, 
high-speed computing; 

• fault-tolerance, reliability, or avail¬ 
ability; or 

• real-time response demands. 

In the second case, distributed com¬ 
putation is forced on a designer because 
of existing, overriding situations such as 

• distributed database systems, 

• automated manufacturing, 

• remote sensing and control, or 

• coordinated decision-making. 

The challenges 

The issues facing the distributed com¬ 
puting community divide roughly into 
two categories: system design issues and 
application-oriented issues. System de¬ 
sign issues can be subdivided into hard¬ 
ware-oriented and software-oriented 
issues. Applications issues, which take 
the perspective of a system user, can be 
thought of as system models and pro¬ 
gramming support. 

System design issues. The hardware- 
oriented issues of system design include 
physical networks and communications 
protocol design, hardware measures for 
fault-tolerance, and physical clock syn¬ 
chronization. 

Fault-tolerance mechanisms generally 
demand redundancy in hardware re¬ 
sources. For example, in the Tandem 
system, which is designed to meet rigid 
reliability and availability requirements 
in a database environment, each hard¬ 
ware component is duplicated. This de¬ 
mands not only hardware, but also soft¬ 
ware to “roll back” the system state to 
the last known consistent state before 
component failure. 

The design of physical networks and 
communication protocols can have a 
direct impact on system efficiency and 
reliability. For example, in the case of a 
system distributed throughout one build¬ 
ing, a carrier-sense protocol on an Ether¬ 
net media is sufficient. But a space- 
borne system, such as the space station, 
requires a radio packet-switched net¬ 
work to function. 

The software-oriented issues of sys¬ 
tem design include distributed algo¬ 
rithms, naming and resource location, 
resource allocation, distributed operat¬ 


ing systems, system integration, reliabil¬ 
ity, tools and languages, real-time sys¬ 
tems, and performance measurement. 

Distributed algorithms encompass 
many fundamental, challenging prob¬ 
lems in distributed system design, in¬ 
cluding distributed mutual exclusion, 
distributed consensus, Byzantine agree¬ 
ment, deadlock handling, logical clocks, 
distributed snapshots, load sharing/ 
scheduling, and crash recovery. Distrib¬ 
uted algorithm design is complicated by 
the lack of both global memory and 
physically synchronized clocks. 

Distributed snapshots and clock syn¬ 
chronization have attracted attention 
as a way to compensate for the lack of 
global memory. A distributed snapshot 
algorithm collects a partial global state 
of a distributed system to help identify 
several interesting properties. Clock 
synchronization schemes compensate for 
the lack of a physically synchronized 
global clock. 

Fault-tolerance and crash recovery 
are gaining importance because distrib¬ 
uted systems are being commercialized. 

Load sharing and distributed sched¬ 
uling techniques improve performance 
and efficiency by effectively distribut¬ 
ing the workload throughout the sys¬ 
tem. Researchers are investigating load 
sharing policies that are stable, efficient, 
and easy to implement. Distributed 
scheduling decomposes a task into sev¬ 
eral subtasks and allocates them over a 
set of processors to hasten computation 
by overlapping subtask execution and 
minimizing communication. Since opti¬ 
mal solutions to this problem are NP 
hard (even if accurate system state in¬ 
formation were available), researchers 
are looking into heuristic methods. 

With performance measurement and 
modeling techniques, performance can 
be predicted and potential design flaws 
identified before an actual system is 
built. Performance analysis of distrib¬ 
uted systems has been done, primarily 
with analytic modeling and simulation, 
but it can be difficult. Thus, empirical 
techniques are needed to study actual 
performance. 

As design techniques approach ma¬ 
turity, many companies and universi¬ 
ties have launched projects to construct 
real-life distributed systems, and a num¬ 
ber of them now have prototype imple¬ 
mentations — for example, Mach at 
Carnegie Mellon University, V-Kernel 
at Stanford University, Sprite at UC 
Berkeley, Amoeba in Amsterdam, Sys¬ 


tem R* at IBM, Locus at UCLA, VAX- 
Cluster at DEC, and the Spring project 
at the University of Massachusetts. 

Applications issues. From the appli¬ 
cation designer’s point of view, which 
includes algorithm design, the first ques¬ 
tion is “What does my system look like?” 

Many models have been proposed and 
continue to be explored. The communi¬ 
cating sequential process model is a very 
simple synchronous message-passing 
model. As the area has matured, howev¬ 
er, the loose structure of the CSP model 
has led to more restricted paradigms, 
such as the rendezvous mechanism of 
Ada and remote procedure call. Some 
models have been proposed to meet the 
needs of specific applications, for exam¬ 
ple, the transaction model as it relates to 
on-line transaction processing. Other 
modeling issues include virtual shared 
memory and decisions about processor 
granularity. 

The application designer’s second con¬ 
cern is the practical matter of program¬ 
ming support. Research in this area brings 
reality to the models described above. 
This reality comes in the form of lan¬ 
guages, operating system interfaces, and 
higher level abstractions for building 
applications such as databases (for ex¬ 
ample, the general-purpose relational 
database Ingres (Interactive Graphics 
and Retrieval System)). In addition to a 
means for specifying computations and 
communications, automated and semi- 
automated tools are needed to help pro¬ 
duce, debug, and verify distributed ap¬ 
plications. In fact, the need for tools is 
becoming a pervasive problem that will 
require a great deal of attention. 

The future of distributed 
computing 

Although distributed computing has 
been an active research topic for at least 
two decades, several design issues still 
face researchers and system builders. 

The first issue involves theoretical as¬ 
pects, including global state, logical/phys¬ 
ical clock synchronization, and algorithm 
verification. Global state is necessary to 
compensate for the lack of global mem¬ 
ory. A distributed snapshot algorithm 
collects a global state of a distributed 
system, which helps identify interesting 
properties, but the lack of global mem¬ 
ory makes verification of distributed al¬ 
gorithms tedious and error prone. Ver- 
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Further reading 

In total, 117 submissions were re¬ 
ceived for this special issue of Com¬ 
puter. The seven articles selected rep¬ 
resent a high level of quality and a 
broad spectrum of relevant areas, but 
many interesting ideas could not, un¬ 
fortunately, be included. Interested 
readers should consult some of the 
sources listed below for additional ma¬ 
terial. The key areas, or subfields, 
within distributed computing are 

• theoretical aspects, 

• distributed algorithms, 

• distributed operating systems, 

• resource management, 

• fault-tolerance and crash recovery, 

• tools and languages, 

• performance evaluation and mea¬ 
surement, 

• experimental systems, and 

• distributed databases. 

Journals: 

IEEE Transactions on Parallel and Dis¬ 
tributed Systems 

IEEE Transactions on Software Engi¬ 
neering, especially the January 1987 
special issue on distributed computing 
systems 

IEEE Transactions on Computers, De¬ 
cember 1988 and August 1989 special 
issues 

Journal of Parallel and Distributed 
Computing (Academic Press) 


ification techniques for shared memory 
systems are not directly applicable to 
distributed memory systems. They re¬ 
quire other techniques (probably snap¬ 
shot-based or temporal logic-based). 

Second, although fault-tolerance and 
crash recovery have already received 
much attention, system reliability will 
become even more important as distrib¬ 
uted systems become more and more 
commercialized. Instead of concentrat¬ 
ing on hardware redundancy, future re¬ 
search efforts should also investigate 
software techniques for achieving fault- 
tolerance. 

Third, tools and languages are badly 
needed. This area includes tools for spec¬ 
ifying, analyzing, transforming, debug¬ 
ging, creating, and verifying distributed 
software, as well as new languages, lan¬ 
guage extensions, operating system 
primitives, compilation techniques, de¬ 
buggers, and software creation meth¬ 
ods. One of the greatest challenges to 
users of distributed systems is the cre- 


ACM Transactions on Computer Systems 
Distributed Computing (Springer-Verlag) 

Real-Time Systems (Kluwer Academic 
Publishers) 

Algorithmica (Springer-Verlag), special is¬ 
sue in 1988 

Professional meetings: 

ACM Symposium on Principles of Distrib¬ 
uted Computing, to be held August 19-21, 
1991, in Montreal 

IEEE International Symposium on Parallel 
and Distributed Processing, to be held 
December 1-5, 1991, in Dallas 

International Conference on Parallel and 
Distributed Information Systems, to be 
held December 4-6, 1991, in Miami 
Beach, Florida 

International Conference on Distributed 
Computing Systems, to be held June 9- 
12, 1992, in Yokohama, Japan 

Meetings with tracks devoted to distribut¬ 
ed computing systems: Computer Soft¬ 
ware and Applications Conference 
(Compsac), to be held September 11-13, 
1991, in Tokyo; International Parallel Pro¬ 
cessing Symposium, to be held March 23- 
26, 1992, in Beverly Hills, California 


See “Calendar" section, pp. 107-112, for contact 
information. 


ation of reliable, working distributed 
software. Advances in theory, practical 
tools, methods, and languages are es¬ 
sential for building reliable and effi¬ 
cient distributed software. 

The fourth area is high-performance 
systems. Constructing massively paral¬ 
lel systems (10 s or more processors) will 
require physically distributed memory. 
Topological, as well as technological, 
issues will continue to be important in 
designing interconnection networks for 
these systems. Technology challenges 
will center on optical communications 
and the VLSI-related issues of module 
integration, multichip and board lay¬ 
out, and packaging. 

Fifth, real-time distributed systems 
will become more important for auto¬ 
mated manufacturing, remote sensing 
and control, and other time-critical mis¬ 
sions. Past research in real-time distrib¬ 
uted systems emphasized efficient task¬ 
scheduling algorithms to meet task 
deadlines under various constraints. 


Texts and tutorials: 

Ananda, A.L., and B. Srinivasan, eds., 
Distributed Computing Systems: Con¬ 
cepts and Structures, IEEE Computer 
Society Press, Los Alamitos, Calif., 
Order No. 1975, 1991.* 

Coulouris, G., and J. Dollimore, Distrib¬ 
uted Systems: Concepts and Design, 
Addison-Wesley, Reading, Mass., 1988. 

Rai, S., and D.P. Agrawal, Advances in 
Distributed System Reliability, IEEE 
Computer Society Press, Los Alamitos, 
Calif., Order No. 1907, 1990.* 

Raynal, M, Distributed Algorithms and 
Protocols, John Wiley and Sons, New 
York, 1988. 

Shatz, S., and J-P Wang, Distributed- 
Software Engineering, IEEE Computer 
Society Press, Los Alamitos, Calif., 
Order No. 856, 1989.* 

Sloman, M., and J. Kramer, Distributed 
Systems and Computer Networks, 
Prentice Hall, Englewood Cliffs, N.J., 
1987. 

Stankovic, J.A., and K. Ramamritham, 
Hard Real-Time Systems, IEEE Com¬ 
puter Society Press, Los Alamitos, 

Calif., Order No. 819, 1988.* 


* For price and order information, call (800) CS- 
books or, inside California, (714) 821-8380. 


Future research will focus on system 
structuring and total system design. 

Finally, as design techniques approach 
perfection, we will see a proliferation of 
actual distributed systems with signifi¬ 
cantly improved fault-tolerance, re¬ 
source sharing, and communications. 
These systems will function as single, 
coherent, powerful virtual machines 
providing transparent user access to 
network-wide resources. ■ 
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An Object-Based 
Taxonomy for Distributed 
Computing Systems 


Bruce E. Martin, Claus H. Pedersen, and James Bedford-Roberts 
Hewlett-Packard Laboratories 


A hierarchy of 
questions and answers 
about the features of 
distributed computing 
systems leads to an 
overall system 
description and 
facilitates system 
comparisons. 


A taxonomy is a classification tool that allows different examples of some 
generic type to be described. The taxonomy presented here is a hierarchy 
of questions and answers about the features of distributed computing 
systems (DCSs). To describe a specific DCS, a taxonomy user traces paths through 
the hierarchy. 

System descriptions produced from the taxonomy can be used as broad summa¬ 
ries. Alternatively, since the descriptions are derived from the same taxonomy, 
they can be used to compare systems with each other or with requirements. At 
Hewlett-Packard Laboratories we have used this taxonomy to describe and 
compare several distributed computing systems. 1 ' 7 We have selectively used exam¬ 
ples from these systems throughout the article. 

Aside from system description, the taxonomy identifies a set of fundamental 
system features and provides terminology that can be used in the general discus¬ 
sion of a DCS. The taxonomy can also serve as the basis for designing a DCS that 
offers novel combinations of features. 

The taxonomy uses terminology from an object-based model of distributed 
computing systems that we present in the section “Modeling distributed comput¬ 
ing systems.” For this reason we describe the taxonomy as being object based, 
though it doesn’t matter whether the DCS is actually object based or not. A DCS 
is any loosely coupled computing system that provides services to support the 
execution and interaction of its components. 

In this taxonomy we emphasize the runtime services the DCS provides to 
applications. Nevertheless, the scope of the taxonomy is not rigidly defined. There 
is no sudden cut-off point where we cease to address issues; rather, as we move 
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Terms used in the taxonomy 


Access control list — A list of an object’s authorized users, 
including their rights to invoke operations. Access control lists 
are held by the object. 

Application — A set of objects that cooperate to provide 
some common benefit. 

Asynchronous operation invocation — An operation invo¬ 
cation for which a new thread of control is created to execute 
the method. Subsequent events of the invoking thread are not 
ordered with respect to the events of the method execution. 
Broadcast — Communication from one source object to an 
unspecified set of target objects. The sending object has no 
way of controlling which objects receive the message. 
Capability — A token that identifies an object such that pos¬ 
session of the token confers access rights to the object. Ca¬ 
pabilities are held by the user of the object. 

Concurrent program — A program that specifies the interac¬ 
tion of concurrent threads. The process of specifying how 
concurrent threads interact is called concurrent programming. 
Concurrent threads — A set of executing threads of control 
with more than one member. 

Correctness criterion — The criterion used to state whether 
a schedule of concurrent threads is correct. 

Distributed computing system (DCS) — A loosely coupled 
computing system that provides services to support the exe¬ 
cution and interaction of its components. 

Event — An action that can be considered to happen instan¬ 
taneously. The events of interest are thread creation, thread 
termination, operation invocation, and operation return. Exe¬ 
cution of method X is given by a pair of events — invoke X, 
return from X. If execution of method X causes operation Y to 
be invoked and its corresponding method to be executed, 
then the events caused by executing method X are invoke X, 
invoke Y, return from Y, return from X. 

Failure atomicity — A guarantee made by a DCS that the ef¬ 
fects of a group of operations are seen entirely or not at all. 

Heterogeneous DCS — A DCS that offers a different service 
or interface at some nodes than at others. 

Homogeneous DCS — A DCS that offers the same service 
and interface at every node. 

Identifier — A value used to distinguish an object. 

Label — A value associated with an object in a label-based 
security scheme. There are two types of labels held by ob¬ 


jects — classification labels and clearance labels. Classifica¬ 
tion labels indicate the level of clearance required to access 
an object. Clearance labels indicate the level of clearance an 
object has been assigned. 

Lock — A construct used to control concurrent access to ob¬ 
jects. Locks may have protocols and notions of compatibility 
associated with them. An exclusive lock lets only a single 
thread access an object. Compatible locks allow multiple 
threads to access an object. See two-phase locking, below, 
for an example of a locking protocol. 

Method — An algorithm implementing an operation. 

Multicast — Communication from a single object to a speci¬ 
fied set of objects. 

Object — See “Modeling with objects” subhead on page 19. 
Operation — See “Modeling with objects” subhead on page 
19. 

Partitioned object — An object whose state or methods are 
distributed on different nodes of the DCS. 

Persistent object — An object whose existence does not 
depend on any given thread of control in the DCS. 
Point-to-point — Communication from a source object to a 
single, specified target object. 

Replicated object — An object with part or all of its state or 
methods replicated in the DCS. 

Restorable object — An object for which prior states may be 
restored under programmer control. 

Serializability — A correctness criterion for scheduling con¬ 
current threads that defines the schedule as correct if it is 
equivalent to some serial (nonconcurrent) execution of the 
threads. 

Synchronous operation invocation — An operation invoca¬ 
tion in which no new thread of control is created. The thread 
migrates to the object on which the operation was invoked. 
Taxonomy — A classification tool that allows different exam¬ 
ples of some generic type to be described. 

Thread of control — See “Modeling with threads” subhead 
on page 19. 

Two-phase locking — A concurrency control protocol that 
ensures serializability. The protocol has two phases — the 
lock acquisition phase and the lock release phase. The proto¬ 
col dictates that once a thread of control has released a lock, 
it cannot acquire additional locks. 


further outside our main areas of inter¬ 
est, the taxonomy becomes sparser and 
questions become broader. 

Using the taxonomy 

Before applying the taxonomy, us¬ 
ers should first define the DCS to be 


described. The definition may be arbi¬ 
trary, but the main point is to establish 
what constitutes the system before try¬ 
ing to classify it. The user must establish 
(1) the services the system provides to 
the applications built over it and (2) the 
services it relies on any underlying plat¬ 
form to provide. 

Once the system has been defined, 


the user can start tracing through the 
taxonomy. Starting at the root of the 
hierarchy, the taxonomy presents a num¬ 
ber of basic divisions. These divisions 
do not require any action from the user; 
they merely set the scene for the ques¬ 
tions that follow. 

Eventually, the divisions lead to ques¬ 
tions about the system. For each ques- 
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Figure 1. The top-level division. 


tion, the taxonomy will pro¬ 
vide a set of possible answers. 

The user must select the an¬ 
swers that apply to the sys¬ 
tem. All the answers for a 
given question will be dis¬ 
tinct from each other; gener¬ 
ally they are not mutually 
exclusive, so many answers 
may apply. For each applica¬ 
ble answer, the taxonomy 
may lead to a further set of 
questions. At some point us¬ 
ers will reach a leaf in the 
taxonomy; this can be either 
a question or an answer. Since 
we have emphasized breadth 
rather than depth, the user may very 
well be able to think of further ques¬ 
tions and answers that could be added 
to the leaves of the taxonomy. 

Taken together, the results — the 
answers selected by the user — provide 
a brief, overall description of the dis¬ 
tributed computing system. 

The taxonomy is presented using both 
figures and text. Each division, ques¬ 
tion, and answer is given a short head¬ 
ing. The figures arrange these headings 
graphically to show how they are relat¬ 
ed to each other. In the text, question 
headings appear in brackets and answer 
headings in parentheses. In the figures, 
division headings are printed in hexa¬ 
gons, question headings in rectangles, 
and answer headings in ovals. 

The text expands on the headings, 
providing explanations and examples 
to help taxonomy users understand the 
questions and answers. 

Modeling distributed 
computing systems 

We use objects and threads to model 
DCSs. By forcing the taxonomy user to 
model systems in this way, the descrip¬ 
tions obtained are more succinct and 
easier to compare. 

Objects are simple and unifying. Tra¬ 
ditional terminology differs for similar 
concepts pursued in different areas of 
computer science. We use object no¬ 
tions to unify different terminology for 
similar concepts. For instance, comput¬ 
er security researchers traditionally dis¬ 
cuss protected resources. We rephrase 
such abstractions using object termi¬ 
nology. 

We assume a general definition of an 


object. The definition is such that di¬ 
verse components of distributed com¬ 
puting systems can be modeled in terms 
of objects, even components that are 
not implemented or originally described 
in this way. For instance, a file can be 
viewed as an object with operations read, 
write, and seek. 

Modeling with objects. An object com¬ 
prises a set of defined states, a current 
state, and a set of operations. The cur¬ 
rent state is always one of the defined 
states. The only way to observe or change 
the object’s current state is to invoke 
one of the operations. An operation is a 
parameterized transformation of an ob¬ 
ject’s current state. An operation may 
yield a result. An algorithm implement¬ 
ing an operation is called a method. A 
method may access the representation 
of the object’s state and may invoke 
operations on other objects. 

Modeling with threads. The defini¬ 
tion of object contains no temporal no¬ 
tions. Therefore, we define threads of 
control to introduce a partial ordering 
of events in the DCS. A thread of con¬ 
trol is a totally ordered set of events 
defined by a programmer. The ordered 
events of a thread ultimately result from 
the execution of a program written in 
some programming language. In gener¬ 
al, no order is assumed for the events of 
different threads. 

In this model of a DCS based on 
objects and threads, the interesting 
events are thread creation, thread ter¬ 
mination, operation invocation, and 
operation return. 

A thread is global to the DCS; it can 
span several objects. A synchronous 
operation invocation causes the thread 
to migrate to the object executing the 


corresponding method. 
When the method completes, 
the thread migrates back to 
the object that invoked the 
operation. An asynchronous 
operation invocation, on the 
other hand, causes a new 
thread to be created. No or¬ 
der is assumed between the 
events of the original thread 
and those of the created 
thread. 

A thread is executing in 
an object if the object has 
started executing the meth¬ 
od but has not yet complet¬ 
ed. If a thread that is execut¬ 
ing in an object invokes another 
operation on another object, the thread 
is executing in multiple objects. 

If, at a given time, there is more than 
one thread in the DCS, the threads are 
called concurrent threads. 

Modeling nonuniform components. 

Each taxonomy question is really many 
questions rolled into one. The taxono¬ 
my user should answer a given question 
for each type of component modeled as 
an object. 

Example: SOS (an object-oriented op¬ 
erating system) provides elementary 
objects that execute within a single 
virtual address space. Elementary 
objects from different virtual address 
spaces can be grouped into fragment¬ 
ed objects. Both elementary and frag¬ 
mented objects fit the taxonomy’s 
basic definition of an object. In de¬ 
scribing SOS, the taxonomy user 
should traverse the taxonomy twice, 
once for elementary objects and once 
for fragmented objects. 

The taxonomy 

As Figure 1 shows, we divide the is¬ 
sues of DCSs into three distinct catego¬ 
ries: threads, object properties, and sep¬ 
aration. The threads subtree explores 
the creation, the number, and the con¬ 
trol of threads in the DCS. The object 
properties subtree explores DCS fea¬ 
tures that are defined for objects in 
isolation. The separation subtree ex¬ 
plores issues that arise because there 
are many objects in the DCS. 

Threads. We examine how threads 
are created, how many threads can ex- 
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Figure 2. Threads. 


ist, and how they are controlled (see 
Figure 2). 

[How created?] Describe how programs 
create threads. For instance, threads 
can be statically declared, dynamically 
created, or created as a result of an 
asynchronous operation invocation. 

[Number in the DCS?] How many 
threads can execute concurrently in the 
DCS? 

(One) The DCS does not support con¬ 
current threads. Only one thread may 
exist in the DCS. 

Example: MS-DOS allows only a 
single thread to execute. 

(Many) Multiple threads may exe¬ 
cute concurrently in the DCS. 

Example: Unix allows multiple 
threads of control to execute. 

[Number in object?] How many threads 
can execute concurrently in an object? 
Remember to answer this question for 
each kind of object in the DCS. Thus, if 
the DCS groups objects in some fash¬ 


ion, it may also be appropriate to an¬ 
swer the question for the group. 

(One) Only a single thread may exe¬ 
cute in the object. Also, state whether 
the DCS allows the single executing 
thread in the object to invoke an op¬ 
eration of the same object. For in¬ 
stance, if foo and bar are operations 
defined on the same object, state 
whether the DCS allows the follow¬ 
ing thread: invoke foo; invoke bar; 
return bar; return foo. 

(Many) The DCS allows multiple 
threads to execute concurrently with¬ 
in a single object. 

[Control?] Haphazard interleavings of 
concurrent threads may result in se¬ 
mantic inconsistencies. A DCS may pro¬ 
duce interleavings according to some 
correctness criterion. Such policies are 
typical of schedulers in database man¬ 
agement systems. Alternatively, the DCS 
may leave management of concurrent 
threads to the programmer. How are 
concurrent threads managed? 

(Correctness criterion) The DCS 


schedules concurrent access to ob¬ 
jects according to some correctness 
criterion. State the correctness crite¬ 
rion. For instance, a two-phase lock¬ 
ing scheduler ensures serializability. 
That is, it schedules a set of a concur¬ 
rent threads such that their effects 
are the same as some serial execution 
of the threads. State if and how the 
object programmer is aware of the 
scheduler. Perhaps it is completely 
hidden. Perhaps the program dynam¬ 
ically acquires locks according to a 
system-defined protocol. Maybe the 
programmer specifies acceptable in¬ 
terleavings based on the semantics of 
the object. 

Example: In Arjuna 6 (a prototype 
object-oriented programming sys¬ 
tem), concurrent threads are seri¬ 
alized. The program acquires locks 
dynamically and the system releas¬ 
es them atomically. Programmers 
can provide scheduling information 
about acceptable interleavings by 
specializing the lock class. 

(Concurrent programming) If a thread 
is programmed to interact with other 
concurrent threads, the interacting 
threads form a concurrent program. 
The process of describing how con¬ 
current threads interact is called con¬ 
current programming. Concurrent 
threads synchronize themselves us¬ 
ing primitives provided by the DCS. 
The application programmer is aware 
of and responsible for the correctness 
of the concurrent execution in the 
DCS. The DCS provides basic tools, 
such as semaphores or monitors, for 
the programmer to use. 

Example: Network Computing Sys¬ 
tem (a remote procedure call sys¬ 
tem) provides mutual-exclusion 
primitives for concurrent program¬ 
ming. 

Object properties. Object properties 
are DCS features defined for objects in 
isolation. As Figure 3 shows, we charac¬ 
terize the object properties supported 
by the DCS. Because the DCS may have 
several kinds of objects, remember to 
explore this subtree for each kind of 
object in the system. 

Persistent. A persistent object does 
not depend on a thread in the DCS for 
its existence. We rejected the informal 
notion that a persistent object “persists 
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by living on a disk.” Just as RAM may 
lose its contents when turned off, a disk 
loses its contents when it is reformatted 
or corrupted. Such ideas of persistence 
are too technology dependent. We also 
rejected the notion that a persistent 
object is one that survives failures. Sur¬ 
vival of failures is an orthogonal issue 
covered in a subsequent section. The 
subtree given in Figure 4 characterizes 
the level of support the DCS provides 
for persistent objects. 

[Specification?] How does the program¬ 
mer specify that an object is to be per¬ 
sistent? 

(Transparent) All objects are persis¬ 
tent. 

(Declarative) The programmer de¬ 
clares in some way that an object is 
persistent. The declarations can be 
either static or processed at runtime. 

[State persistence?] How does the DCS 
support the persistent state for persis¬ 
tent objects? 

(Transparent) The persistent state is 
automatically achieved without any 
programmer involvement. 

(Tools) The programmer must pro¬ 
vide code to support the DCS to ob¬ 
tain the persistent state. 

Example: Arjuna requires applica¬ 
tion programmers to provide 
save_state and restore_state meth¬ 
ods for persistent objects. 

Restorable. With a restorable object, 
prior states of the object can be restored 
under programmer control. Note that 
prior states of an object can be recov¬ 
ered automatically by a DCS in the event 
of a failure. Such activities are charac¬ 
terized in a later section concerning 
partial failures and the execution guar¬ 
antees a DCS makes. This subtree, shown 
in Figure 5, is concerned with the model 
of state restoration presented to, and 
under control of, the programmer. 

[Granularity?] What is the granularity 
of a restorable state? State whether a 
single object is restorable. State wheth¬ 
er a group of objects can be restored to 
mutually consistent states. 

Example: A program may explicitly 
abort a computation in Arjuna. The 
set of accessed objects are restored to 
their original states. 



Figure 4. Persis¬ 
tent objects. 



[Decision to save?] Describe whether 
(and how) the programmer or the sys¬ 
tem decides to save the current state of 
an object. For example, the state of an 
object might be saved every n updates, 
every t seconds, when some relation 
between two objects holds, or when a 
commit or savestate statement executes. 

[Decision to restore?] Describe wheth¬ 
er (and how) the programmer or the 
system indicates that a prior state of an 
object should be restored. For example, 
the programmer might indicate it with 
an abort or an undo statement. 

[Decision to discard?] Describe wheth¬ 
er (and how) the programmer or the 
system decides to discard prior states of 
an object. For instance, memory may be 
reclaimed if no more is available or if 
the programmer requests it. 

[Programmer involvement?] How is the 


programmer involved in supporting re¬ 
storable objects. 

(Transparent) All objects are restor¬ 
able. The programmer uses the con¬ 
structs to save and restore states di¬ 
rectly. 

(Declarative) The programmer de¬ 
clares that an object is to be restor¬ 
able. 

(Tools) The programmer is involved 
in implementing this property. For 
instance, the programmer might pro¬ 
vide code that the DCS executes. 

Replicated. An object is replicated if 
the DCS maintains multiple copies of 
the object that a client object can iden¬ 
tify as a single object. Objects may be 
replicated to enhance performance or 
to increase availability. Ideally, the rep¬ 
licas always exhibit the same behavior, 
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Figure 6. Replicated objects. 


Figure 7. Parti¬ 
tioned objects. 



but a DCS may trade consistency for 
performance. An application program¬ 
mer may be involved in replicating the 
components. (See Figure 6.) 

[How?] How does the DCS support rep¬ 
lication? 

(Hardware) The object’s state and 
methods are replicated at different 
sites to improve performance or avail¬ 
ability. 

(Software) The DCS supports execu¬ 
tion of replicated operations; that is, 
the DCS executes multiple implemen¬ 
tations of the same operation. The 
probability that the same software 
fault will appear in all implementa¬ 
tions is low, so the object remains 


highly available in spite of software 
faults. 

[Consistency sacrifice?] Describe cir¬ 
cumstances under which the DCS sacri¬ 
fices the consistency of the replicated 
object. For instance, if the system up¬ 
dates all available replicas, consistency 
might be sacrificed if the network parti¬ 
tions into two subnets that cannot com¬ 
municate. 

[Replication interface?] How must the 
programmer consider replication in the 
DCS? 

(Transparent) The programmer nev¬ 
er considers the replication of objects. 
All objects are replicated, or the DCS 
decides which objects to replicate. 


(Declarative) The programmer de¬ 
clares which objects should be repli¬ 
cated. 

(Tools) The programmer is involved 
in replication by, for example, speci¬ 
fying where the replicas should exist 
or assigning weights to the replicas 
for weighted-voting consistency 
schemes. 


Partitioned. An object is partitioned 
if the object’s state and methods are 
fragmented on different nodes in the 
DCS. (See Figure 7.) 

[Split?] How can an object be parti¬ 
tioned? 

(State) An object’s state can be parti¬ 
tioned into pieces that reside on dif¬ 
ferent nodes. 

[Granularity?] What are the mini¬ 
mal state components that can be 
partitioned? 

Example: The state of an SOS 
fragmented object may reside on 
different nodes. An instance vari¬ 
able of the fragmented object 
cannot be partitioned; it resides 
on a single node. 

(State/code) The object’s state may 
be on a different node from where its 
code executes. 

(Code) The object’s code may be par¬ 
titioned into pieces that execute on 
different nodes. 

[Granularity?] What are the mini¬ 
mal code components that can be 
partitioned? Perhaps each method 
of an object can execute on a differ¬ 
ent node, or maybe all methods 
implemented in a specific language 
must execute on a specific node. 

Example: The methods of an SOS 
fragmented object may exist on 
different nodes. 

[Control?] How is the partitioning of an 
object determined? 

(Transparent) The DCS decides how 
an object is partitioned. For instance, 
it may have algorithms that change 
the way an object is partitioned for 
performance reasons. 

(Declarative) The programmer can 
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statically declare how an object is to 
be partitioned. 

(Tools) The DCS provides tools the 
programmer can use at runtime to 
affect the way objects are partitioned. 
For instance, there may be some prim¬ 
itives that allow the programmer to 
move an object’s method to another 
node. 

Protected. The DCS may provide ser¬ 
vices that allow owners to selectively 
protect their objects from other users. 
(See Figure 8.) 

[What is protected?] What objects does 
the DCS protect? Possible answers in¬ 
clude machines, applications, methods, 
data, and groups of objects. 

[What is trusted?] The question of what 
is trusted may apply to both objects and 
communication paths between objects. 
Also, state what things are trusted for 
and how trust is propagated. For in¬ 
stance, a name server may be trusted to 
keep names confidential. Clients may 
trust it because they trust the communi¬ 
cation path to it and because they re¬ 
ceived the name server’s address from a 
trusted source. 

[Services?] What protection services 
does the DCS offer? 

(Confidentiality) Information is not 
made available or disclosed without 
authorization. 

(Integrity) Information cannot be al¬ 
tered or destroyed without authori¬ 
zation. 

(External authentication) The iden¬ 
tity of users outside the DCS is veri¬ 
fied. 

(Nonrepudiation) A user cannot lat¬ 
er falsely establish that he has or has 
not interacted with an object. 

(Access control) Users cannot inter¬ 
act with objects in specific ways 
without authorization. Describe the 
mechanisms used to support access 
control. For instance, are they based 
on capabilities, labels, or access con¬ 
trol lists? 

[Techniques?] Describe any visible un¬ 
derlying techniques by which the DCS 
supports protection services — for ex¬ 
ample, data encryption or key manage¬ 
ment techniques. 


E 


What is 
protected? 

What is 
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Services? 
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Figure 8. Protected objects. 



Figure 9. Cre¬ 
ation and destruc¬ 
tion of objects. 


Existent. This subtree, shown in Fig¬ 
ure 9, explores the creation and de¬ 
struction of objects. 

[How created?] Describe the program¬ 
mer’s view of an object’s creation. 
[How destroyed?] What can cause the 
destruction of an object? 

(Programmer) The programmer can 
write code that deletes an object. 

(Related objects) The object’s exist¬ 
ence depends on other related ob¬ 
jects. 

[How?] How does the object de¬ 
pend on these relationships? By 
garbage collection, for example, 
whereby an object may be deleted 


automatically once there are no 
references to it. Perhaps an object 
is deleted when its container object 
is deleted. 

(Threads of control) The DCS may 
delete an object when no threads of 
control are associated with it. 

Separation. The object properties 
considered in the previous section could 
all be associated with a single object. In 
this section we consider issues that arise 
because we model a DCS as a collection 
of interacting objects. The goal of DCS 
design is to achieve an optimum degree 
of integration of these objects without 
sacrificing the flexibility and resilience 
obtained through separation. Thus, in 
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[How obtained?] How is the identifier 
obtained once it exists? 


Separation 



Figure 10. Separation. 


this part of the taxonomy we consider 
issues of both managing separation and 
achieving integration. (See Figure 10.) 

Identification. Identification is the 
process by which the DCS and the ap¬ 
plication programmer distinguish ob¬ 
jects. An identifier (ID) is a value used 
to distinguish an object. The DCS asso¬ 
ciates the identifier’s value with the iden¬ 
tified object. (See Figure 11.) 

[Identifier types?] What are the types 
of identifier? The system may support 
many different types. These types may 
each address different objects, or they 
may overlap such that a given object can 
be distinguished by many types of iden¬ 
tifier. Verify that the identifier is passed 
across the interface between the appli¬ 
cation and the system as a distinct pa¬ 
rameter. 

Example: Unix files can be identified 

by Unix path names, file descriptors, 

or i-numbers. 

Answer the remaining question for each 
type of visible identifier. 

[Identifier scope?] What is the identifi¬ 
er’s scope; that is, what is the domain in 
which the identifier can be applied? 


Often, the scope of one identifier is 
defined by another object. 

Example: The scope of a Unix file 
descriptor is a process and its descen¬ 
dants. 

[Continuity guarantees?] What conti¬ 
nuity is guaranteed about the referenced 
object each time a particular applica¬ 
tion uses an identifier? For instance, 
what can you say about the object’s 
type, successive states, location, owner, 
and access rights each time the identifi¬ 
er is applied? 

Example: A Unix file descriptor guar¬ 
antees type continuity; it always iden¬ 
tifies a file. 

Example: A Network Computing Sys¬ 
tem UUID (universally unique iden¬ 
tifier) does not guarantee location 
continuity. The identified object’s lo¬ 
cation may change. 

[How established?] How is the identifi¬ 
er established in the first place? This is 
a broad question that leads to many 
others. For instance, who establishes 
the identifier and when? If it is the 
application, what constraints are there 
on the value that may be assigned to the 
identifier? If it is the DCS, what algo¬ 
rithm is used to establish the value? 


[How bound?] How is the identifier 
bound to an object? If it is visible to the 
programmer, describe how the DCS lo¬ 
cates an object. 

[Integrity support?] How rigorously does 
the system support the identification 
scheme’s integrity? For instance, what 
happens if the programmer tries to use 
an identifier when the associated object 
no longer exists? Also, can identifier 
values be reused for different objects 
within the system’s lifetime? Finally, 
what happens if identifier values are 
used outside their scope? For instance, 
what happens if an identifier value was 
intended only to distinguish objects on 
machine A and a programmer tries to 
apply it on machine B ? 

Communication. Communication is 
the process by which different objects 
interact. (See Figure 12.) Here we dis¬ 
tinguish between the object that insti¬ 
gates communication, referred to as the 
source object, and the object(s) the 
source is trying to communicate with, 
referred to as the target object(s). 

[Paradigm?] What communication par¬ 
adigms does the DCS support? 

(Operation invocation) The source 
object can invoke operations on the 
target object. 

[Coordination?] How are the source 
and target objects coordinated dur¬ 
ing the operation invocation? For 
instance, do they operate synchro¬ 
nously or asynchronously? In the 
asynchronous case describe what 
happens to the return parameters 
from the invocation. 

(Shared state) The communication is 
based on the changing state shared 
among the communicating objects. 
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Figure 11. Identification. 
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The shared state can be either global 
variables or the “public” state of an 
object. The shared state can be read 
and written by all objects that share 
it, without invoking operations. 

(Pure data) A pure-data transmis¬ 
sion mechanism is supported. The 
DCS does not guarantee how the re¬ 
ceiving object processes the data that 
it receives; it only supports delivery 
of the data. Describe what kind of 
buffering policies are used for the 
sending as well as the receiving end. 
State whether the data is typed or 
untyped. 

[Enabling?] What information or ac¬ 
tions are required to enable communi¬ 
cation between objects? Information 
may include things such as the identifi¬ 
er, type, or location of the target object. 
If the target object’s location must be 
supplied, how is it specified and where 
does the programmer get this informa¬ 
tion? Actions may include the program¬ 
mer’s setting up a connection before 
trying to communicate. If so, describe 
how the programmer sets up a connec¬ 
tion. 

[Configuration?] What source-object- 
to-target-object configurations are pos¬ 
sible? These can be broadcast, multi¬ 
cast, or point to point. In broadcast 
mode, communication is from one source 
object to an unspecified number of tar¬ 
get objects. The sending object has no 
way of controlling which objects receive 
the message. In multicast mode, com¬ 
munication is from one source object to 
a specified set of target objects. In this 
case, state whether there may be replies 
associated with the multicast. Finally, 
in point-to-point mode, communication 
is from one source object to one target 
object. 

[Guarantees?] What guarantees are 
made about the communication service? 
For instance, the communication may 
be guaranteed to be real-time preserv¬ 
ing (isochronous). In this case, time in¬ 
tervals between each successive sub¬ 
mission of information will be preserved 
such that the same intervals will apply 
at the receiving end. Another possible 
guarantee is “at most once,” when the 
information is guaranteed to arrive no 
more than once at the target object(s). 
The communication service may guar¬ 
antee that the order of information sent 
by one thread of control will be pre¬ 
served upon arrival at the target object, 



Figure 12. Communication. 
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Figure 13. Partial 
failures. 


or it may guarantee that no data will be 
lost in the communication process. There 
are many possible answers. 

Partial failures. A significant differ¬ 
ence between distributed and central¬ 
ized systems is the possibility of partial 
failure of a computation. The interac¬ 
tions between two or more objects may 
be interrupted by processor, storage, or 
communication failures, and some or 
all of the objects may remain active. 
This subtree, shown in Figure 13, deals 
with whether and how a DCS supports 
the programmer in handling partial fail¬ 
ures. 

[Types of failure?] List the types of 
failures for which the DCS provides 


some kind of execution guarantee. For 
each type of failure, answer the remain¬ 
ing questions. 

[Execution guarantees?] A DCS may 
make certain guarantees about execu¬ 
tion to help the programmer in dealing 
with partial failures. What are those 
guarantees? For instance, the DCS may 
guarantee fail-stop behavior, or it may 
ensure that a group of operations are 
failure atomic, that is, that the effects of 
all operations are seen or none of them 
are seen. 

Example: Arjuna ensures failure ato¬ 
micity for a group of operations. 

[Programmer involvement?] State 
whether the programmer is involved in 
handling partial failures, and if so how. 
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(Transparent) The pro¬ 
grammer is not involved. 
Partial failures for all ap¬ 
plications are handled 
equivalently. 

(Declarative) The pro¬ 
grammer must declare 
something about the code. 
For instance, the program¬ 
mer declares that execu¬ 
tion guarantees should be 
provided for a block of 
code. 

(Tools) The programmer 
is involved in handling 
partial failures. For in¬ 
stance, the programmer 
might have to provide a 
method to undo the ef¬ 
fects of an operation. 



Figure 14. Migration. 


Migration. In the DCS, 
objects can move from one 
location to another. (See Figure 14.) 

[Who decides?] Who decides to move 
an object? 

(DCS) The DCS can move objects 
without a specific instruction from 
the programmer. 

[Why?] Why does the DCS move 
objects? It may be to reduce com¬ 
munication or storage costs, or to 
balance its processing load. 

Example: The Emerald system 
moves objects to reduce commu¬ 
nication costs. 


^Underlying^ ^ Inherent ^ 


ly introduced in the DCS de¬ 
sign by enumerating differ¬ 
ent options for different 
nodes, or it can fail to be 
excluded by an incompletely 
defined design. (See Figure 
15.) 

[Cause?] What causes the 
heterogeneity observed by 
the programmer? 

(Underlying) The under¬ 
lying platform on top of 
which the DCS executes 
is both visible to the pro¬ 
grammer and heteroge¬ 
neous. 

Example: The Network 
Computing System lets 
an object on an Intel 
80386-based machine 
running MS-DOS in¬ 
voke an object on a 
Motorola 68000-based ma¬ 
chine running Unix. The under¬ 
lying hardware and operating sys¬ 
tem architectures are visible to 
the programmers of both objects. 
(Inherent) The DCS itself may offer a 
different service or interface at some 
nodes than at others. 

Example: NCS supports both C and 
Pascal programming languages. In¬ 
terfaces to the NCS services vary, 
depending on the programming lan¬ 
guage. 


(Programmer) The programmer can 
issue “move” commands in the appli¬ 
cation program, causing the DCS to 
move objects. 

Example: The Emerald system pro¬ 
vides programmers with a call-by¬ 
move parameter-passing mode. 
Call-by-move provides a hint to the 
Emerald compiler to move an ob¬ 
ject passed as an argument to a 
remote site. 

[How?] How is an object moved? 

(Fixed) The DCS does it in one spe¬ 
cific way. 

(Fixed declarative) The programmer’s 
declarations indicate one of a fixed 
number of alternatives. For example, 
the programmer may declare that ref¬ 
erenced objects are not to be moved 
when the referencing object is moved. 


Figure 15. Heterogeneity. 


(Enumerable declarative) By com¬ 
bining declarations, the programmer 
can define new kinds of behavior to 
be associated with the moving of an 
object. 

(Tools) The programmer writes exe¬ 
cutable code to support the DCS in 
moving an object. 

Heterogeneity. A homogeneous DCS 
offers the same service and interface at 
every node. This means that a program 
written on one node can execute on any 
other node in the system. A heteroge¬ 
neous DCS provides different services 
or interfaces at different nodes; conse¬ 
quently, the portability of programs is 
reduced. Heterogeneity can be explicit¬ 


I nevitably, we spent much time dis¬ 
cussing the completeness and or¬ 
thogonality of the system features 
by which we structured our taxonomy 
of distributed computing systems. How¬ 
ever, space limitations prevent us from 
including those discussions here. Read¬ 
ers with different backgrounds are like¬ 
ly to favor different structures. We also 
had difficulty designing questions that 
addressed qualitative issues; we pre¬ 
ferred to ask about the services the DCS 
provides. In particular, we decided not 
to address performance issues, since we 
felt these might overwhelm other is¬ 
sues. 

Our experience using the taxonomy 
was reassuring. First, we were able to 
produce short, comparable system de¬ 
scriptions. Furthermore, we found that 
our minimal model of objects and threads 
and the associated terminology was suf- 
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ficient to describe real systems. In par¬ 
ticular, we found the taxonomy useful 
for leading a user through the DCS in a 
systematic way. 

The taxonomy emphasizes breadth 
rather than depth. It touches many ar¬ 
eas of computer science, including secu¬ 
rity, naming, concurrency, and fault tol¬ 
erance. Surveys exist that probe each 
area in more detail. 810 ■ 
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Logical Time in Distributed 
Computing Systems 


Colin Fidge, University of Queensland 


U nlike conventional sequential programs, the computations performed by 
distributed computing systems do not yield a linear sequence of events. 
The interrelationships between the events performed in a distributed 
system inherently define a partial ordering — genuinely concurrent events have no 
influence on one another. 

In the past, designers have typically used a simplified view of distributed 
computations, imposing an interleaved total ordering on the events performed. 
However, new computing concepts now let us use the full partial ordering of events 
as defined by their causal relationships, that is, the ability of one event to directly, 
or transitively, affect another. In this article I define this partial ordering, describe 
its generalized and practical implementations in terms of partially ordered logical 
clocks, and summarize some current applications of the new technology. 


Partially ordered 
logical clocks can 
provide a decentralized 
definition of time for 
distributed computing 
systems, which lack a 
common time base. 
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Definition 

For a system using both asynchronous and synchronous message-passing and 
process-nesting, the causal relationships between events in a distributed compu¬ 
tation are captured as follows. 

The relation “happened before,” denoted is the smallest relation satisfying 

the six conditions listed below. It is an irreflexive, transitive relation among the 
events performed during a given computation. An event is a uniquely identified 
runtime instance of an atomic action of interest, and a computation is a particular 
run or execution of the distributed computing system. A computation consists of 
one or more possibly nested process instances, which are uniquely identified 
runtime instantiations of a particular process definition. 

• Condition 1: Sequential behavior. If events e and/occur in the same process 
instance p, and/occurs after e, then e -* *f. 

• Condition 2: Process creation. If event e and process instance q occur in 
process instance p, event/occurs in q, and q begins after e, then e ->/. 

• Condition 3: Process termination. If event e and process instance q occur 
in process instance p, event / occurs in q, and e occurs after q terminates, 
then/—» e. 

0018-9162/91/0800-0028$01.00 © 1991 IEEE 
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Figure 1. A distributed computation. Expressions in braces show the partially 
ordered time at each event. Solid arrows represent flow control; dotted arrows 
show interprocess communication. 


• Condition 4: Synchronous (unbuf¬ 
fered) message-passing. If event e is a 
synchronous input (output) and event 
/is the corresponding output (input), 
and there is an event g such that e -> g, 
then / -> g. If there is an event h such 
that h e, then h ->/. 

• Condition 5: Asynchronous (buff¬ 
ered) message-passing. If event e is an 
asynchronous send, and event / is the 
corresponding receive, then e —> /. 

• Condition 6: Transitivity. If e -» f 
and /-> g, then e -> g. 

An event e “occurs in” a process 
instance p if p executes e. A process 
instance q occurs in a process instance 
p if q is a subprocess of p. “After” is 
used only when referring to actions 
that occur within a single process in¬ 
stance. Each process consists of a se¬ 
quence of actions. 1 

Partially ordered 
logical clocks 

Figure 1 shows a computation per¬ 
formed by a distributed program P. 
Shortly after it starts executing, P 
spawns two process instances Q and R. 
All three processes perform a number 
of events. Some are actions internal to 
a process, such as E, or are communica¬ 
tion actions such as G. (For clarity I 
treat process creation and termination 
as special cases, although it is possible 
to consider these actions as synchro¬ 
nizing events.) After performing event 
H, process R creates two processes S 
and T, and suspends itself during the 
lifetime of its offspring. Processes P 
and S communicate via synchronous 
message-passing; event F outputs a 
message that is simultaneously input 
by event I. Processes P and Q commu¬ 
nicate via asynchronous message-pass¬ 
ing; event G denotes the sending of a 
message later received by event C. 

After processes S and T terminate, 
process R resumes execution and per¬ 
forms event L. After processes Q and 
R terminate, the main program, pro¬ 
cess P, performs a final event M, and 
the computation ends. 

Partially ordered logical clocks char¬ 
acterize all interrelationships between 
these events. In Figure 1 the annota¬ 
tion at each event shows the partially 
ordered time at that point in the com¬ 


putation. I explain the maintenance and 
use of this information below. 

Notation. Because the time readings 
must be partially ordered, a single inte¬ 
ger or real value is inadequate as a data 
structure. Assume that p, denotes a pro¬ 
cess instance uniquely identified by i. 
We can represent a partially ordered 
time reading made by p , with a set of 
pairs 

{(*>!)„..,(/,«,)} 

Here each pair consists of a process 
instance identifier j and a numerical 
“counter” value n t representing the val¬ 
ue of the counter in p t as perceived by p,. 
Each process thus maintains knowledge 
of the counters in all other processes of 
which it has heard. Process instances 


not represented in the set have the de¬ 
fault counter value 0. 

Assume that e, represents a unique 
event e performed by process instance 
Pi, and t e . is the time stamp attached to 
some permanent record of the execu¬ 
tion of this event. Then t e .(j) is the value 
of the counter for p ; in this time stamp. 

For example , iff Figure 1, 

to = {(P,4), (R,l), (S,l)) 

is the time when process P performed 
event G. (Because event names are 
unique in Figure 1, I omit the process 
identifier subscripts: G is equivalent to 
G P .) From this we can determine the 
“local” counter value for process P at 
that time, 

'g(P)=4 
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and the last known value for process S, 

*o(S) = 1 

When it performed event G, process P 
had received no information from pro¬ 
cess Q,hence 

f c (Q) = o 

A handy function in the following 
definitions is max. Given one or more 
partially ordered time readings, max 
returns a time reading in which every 
counter is set to the maximum of all 
corresponding values, in the arguments 
presented to it, for example, 

max({(i, 2), OM), (*,3)}, {O',4), (*,1)}) 
= (0,4), OM), (fc,3)) 

The counter for pj has the default value 
0 in the second argument to max above. 

Rules. A computation can maintain a 
partially ordered logical clock using nine 
rules. 2 For the rules below to apply, 
each process instance p, created during 
the lifetime of the computation (includ¬ 
ing the outer-level main program) must 
maintain an auxiliary variable c, to hold 
the current partially ordered time as 
perceived by p t . 

• Rule A: Initialization. When the pro¬ 
gram begins execution, the time is ini¬ 
tialized to the empty set, that is, c m := {}, 
where m is the process instance identi¬ 
fier associated with the main program. 

Since zero-valued counters are implicit, 
{} is equivalent to the infinite set {(i,0), 
0,0),...) for every possible process iden¬ 
tifier. 

• Rule B: Ticking. Whenever a pro¬ 
cess instance p, performs an event, it 
increments c,(i) at least once. 

For instance, in performing event D, 
process Q increments its own counter 
from 2 to 3. 

In Figure 1 each counter has been 
incremented exactly once for each event 
performed. However, the rules are val¬ 
id for any number of “ticks,” as long as 
the counters never decrease. 

•Rule C: Monotonically increasing 
counters. No counter in any c, is ever 
decremented. 

• Rule D: Process creation. Whenever 
a process instance p, creates a set of 



Because the time readings 
must be partially ordered, a 
single integer or real value 
is inadequate as a data 
structure. 


process instances p ; ,...,p„ they each in¬ 
herit the current time from p h that is, 
Vx:{/.../) ■ c x := c,. 

Thus, when process R spawns process¬ 
es S and T, they both learn that the 
counters for P and R have value 1. They 
also create pairs for themselves the first 
time they each perform an event (K and 
I), 

• Rule E: Process termination. When¬ 
ever a set of process instances p j ,...,p l 
terminates, the parent process instance 
Pi merges all the children’s logical clocks 
by maximizing the counter values, that 
is, c, := max(c i ,Cj,...,c l ). 

In this way process R learns of all activ¬ 
ity known to its offspring S and T when 
they terminate (including updated 
knowledge of process P). The main pro¬ 
gram P (which cannot terminate until 
all processes it has created have termi¬ 
nated) similarly learns from the demise 
of Q and R. 

•Rule F: Synchronous events. Dur¬ 
ing a synchronizing event, all process 
instances involved (p t ,...,p,) maximize 
their local clocks using the counters 
from every other participating process 
instance, that is, Vx:{/.../) • c x := 
max(Cj,...,c,). A computation applies this 
rule only after any increments required 
by rule B. 

Thus, during the synchronous message¬ 
passing action represented by events F 
and I, process S learns of the time in 
process P and vice versa: Logical time 
information is exchanged in both direc¬ 
tions (hence the double-headed arrow 
in Figure 1). This happens because the 
synchronization resulting from unbuf¬ 
fered message-passing is symmetric: 
Both sender and receiver block. Figure 
1 shows only a biparty interaction, but 


rule F allows for any number of syn¬ 
chronizing processes. 

Asynchronous communication is 
asymmetric (only receivers block) and 
hence requires two rules: 

• Rule G: Sending. Whenever a pro¬ 
cess instance p, sends a message, that 
message carries the current value of c,. 
A process applies this rule only after 
any increments required by rule B. 

• Rule H: Receiving. Upon receiving a 
message, the receiving process instance 
Pj maximizes its counter values using 
those received in the piggybacked time 
stamp c rectived , that is, c, := max(c p c received ). 

Thus event C allows process Q to learn 
of those events known to process P when 
event G was performed. Although Fig¬ 
ure 1 shows only a biparty communica¬ 
tion, these rules also apply to broadcast 
messages. 

The logical clock information is al¬ 
ways piggybacked onto existing com¬ 
munication pathways and thus must re¬ 
flect the structure of the computation. 

•Rule I: Time-stamping. The time 
stamp t e ., associated with the execution 
of event e, by process instance p„ is the 
value of c, immediately following the 
application of rules B through H. 

Finally, with these rules in place, we 
can determine the “happened before” 
relations using the comparison proper¬ 
ty of such time stamps: 

•Comparison property. Given two 
time stamps t e , and t f _, event e, happened 
before event/) if and only if has knowl¬ 
edge of process p, as recent as the execu¬ 
tion of e„ but not vice versa, that is, 

«. -»//~ a,( o ^ ms)) a (m < t fj Q)) 

We need to compare only two pairs 
from the sets to establish whether there 
is a causal relationship between the two 
events. The first comparison is true if 
and only if e, can causally affect/). The 
second comparison precludes reflexivi- 
ty because it would be nonsensical to 
say that an event happened before it¬ 
self. 1 (Because synchronously commu¬ 
nicating processes may independently 
time-stamp their part of a shared event, 
as do F and I in Figure 1, it may not 
always be easy to directly test e, */).) 

Elsewhere I have formally shown that 
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Tests for e ->/ where 

• e and/are the same event: 

(2£2)a(2 3 2) => -i(C —> C) 

• e and/are different events in the same process: 

(1 < 3) a (1 < 3) =* B -> D 
(2 31) a (2 31) => -i(C —> B) 

• e and/are in different processes with an intervening communication 
action: 

(2 3 4) a(0<3) => E->D 
(2 30) a (3 3 2) => -i(J —> E) 

• e is in a subprocess of the process containing / or vice versa: 

(1 £ 1) a (0 < 2) => H -» J 
(5 33) a (2 31) => -i(M —> I) 

• e and/are different parts of a synchronous communication event: 

(3 < 3) a (1 3 1) ^ -n(F^I) 

(1 < 1) a (3 3 3) =* —• (I —> F) 

• e and/are “potentially concurrent”; that is, there is no causal relationship 
between them: 

(2 3 0) a (1 < 2) =* -n(C^J) 

(2 3 1) a (0 < 2) =* -,(J^C) 

(1 3 0) a (0 < 2) =* -i(K —> J) 

(2 3 0) a (0 < 1) =* —i (J —► K) 


Figure 2. Some “happened before” relationships defined between two arbitrary 
events e and /by the time stamps in Figure 1. 


these rules are sufficient to implement 
the “happened before” relation. 2 The 
rules are robust enough for asynchro¬ 
nous message “overtaking” (that is, non- 
FIFO queuing of messages destined for 
a particular process instance). The rules 
also preserve the equivalence between 
asynchronous message-passing and syn¬ 
chronous message-passing with an in¬ 
tervening buffer process, and between 
synchronous message-passing and a sin¬ 
gle event shared among the communi¬ 
cating processes. 

As Figure 2 shows, substituting the 
appropriate counter values from the time 
stamps into the formula from the com¬ 
parison property establishes the rela¬ 
tionships defined by the computation in 
Figure 1. The final category in Figure 2 
shows the principal advantage of par¬ 
tially ordered logical clocks over previ¬ 
ous time-stamping methods. 1 Where no 
causal relationship exists between 
events, no arbitrary ordering is imposed 
on them. Thus we can tell, for instance, 
that events K and J could occur in either 
order, or at exactly the same time. Even 
though Figure 1 suggests that K oc¬ 
curred before J in real time (taking a 
line drawn horizontally through the di¬ 
agram to represent an instant in global 
real time), the logical behavior of the 
computation does not enforce this tem¬ 
poral ordering. A slightly different in¬ 
terleaving of the same computation may 
result in J occurring before K. (Think of 
the dots in Figure 1 as beads free to slide 
up and down the time lines, as long as 
they do not violate causality by, for 
example, causing communication arrows 
to point backward.) 

Optimizations 

In their full generality, as described 
in the previous section, partially ordered 
logical clocks may be impractically ex¬ 
pensive for long-lived computations. For 
instance, the rules placed no upper bound 
on the size of the set of pairs, and their 
number was limited only by the number 
of process instances created at runtime. 
Nevertheless, several optimizations are 
possible, depending on the application 
environment in which the clocks will be 
used. 

Static number of processes. Where 
there is no process-nesting, and the sys¬ 
tem knows the number of processes to 
be created at compile time, the “set of 


pairs” data structure is unnecessary. 
Instead, each process can use an array 
of counters, with one element reserved 
per process. 3 

This frequently used optimization is 
known as “vector time” 3 because each 
clock reading is a vector (array) of 
counter values. It has the obvious ad¬ 
vantage of placing an upper bound on 
the storage requirements for the auxil¬ 
iary clock variables. In a formal proof, 
Charron-Bost demonstrated that a vec¬ 
tor of length n is minimal for n static 
processes. 4 

The vector-time optimization can be 
applied to languages with nested con¬ 
currency if they do not allow recursive 
process definitions. 2 This restriction 
means that only one instance of each 
static process definition can execute at 
any given time. The system can deter¬ 
mine from the source code the maxi¬ 
mum number of runtime process in¬ 
stances simultaneously executing and 
reserve only one vector element for each. 
Every time a particular process defini¬ 
tion is instantiated, it uses the same 


element in the logical clock vector, be¬ 
cause no other copies of itself are cur¬ 
rently running. 

Comparisons known a priori. So far 

we have assumed that the computation 
maintains counters for every process 
instance. However, if we know in ad¬ 
vance the processes that contain the 
events we wish to study, then we need to 
keep counter values only for those pro¬ 
cesses. 5 Nevertheless, other “uninter¬ 
esting” processes must still maintain an 
auxiliary clock variable and transfer in¬ 
formation at communication events. 
Otherwise, the partial ordering may fail 
to correctly reflect transitive interpro¬ 
cess dependences. All processes and all 
synchronizing actions in a computation 
must actively participate. 1 

Only new values piggybacked. When 
the number of processes in the vector¬ 
time model is large, the transmission of 
the clock arrays during message-pass¬ 
ing represents a significant overhead. 
In such cases each process can main- 
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tain, via two further auxiliary arrays, 
the value of the “local” counter when a 
vector was last sent to each other pro¬ 
cess, and when each counter for other 
processes was last updated. Using this 
information, the process can piggyback 
on an outgoing message only those 
counter values that have been modified 
since the last communication with the 
target process, assuming message over¬ 
taking is precluded. 6 

Implementations and 
applications 

Partially ordered logical clocks have 
been used in a number of practical and 
theoretical areas. 

Languages. Inmos’s Occam has only 
one interprocess communication mech¬ 
anism, synchronous message-passing, 
and nested concurrency without recur¬ 
sion. Thus, programmers can easily add 
partially ordered clocks. I have experi¬ 
mentally introduced “logical timers” in 
a way consistent with Occam’s existing 
real-time timer. 2 

So far we have assumed that mes¬ 
sage-passing is the only interprocess 
communication medium. Languages that 
allow interprocess synchronization in 
other ways — for example, through ac¬ 
cess to shared memory, monitors, and 
semaphores — must also incorporate 
rules for such synchronization. 

Bryan has defined partially ordered 
time for Ada. 7 In Ada, there are several 
unusual ways that tasks (processes) de¬ 
fine causal relationships between events. 
The Ada rendezvous causes two tasks 
to synchronize while the “accept” code 
is executed, after which independent 
execution continues. One task can un¬ 
conditionally “abort” another. Unhan¬ 
dled exceptions may propagate to an¬ 
other task. When shared variables are 
used, the Ada standard guarantees syn¬ 
chronization only at certain points in 
the computation. Bryan has formally 
defined the causal relationships for all 
of these activities. 

Debugging distributed systems. Pro¬ 
grammers trying to debug distributed 
computing systems are faced with a frus¬ 
trating inability to see what is happen¬ 
ing in the network of processes. 2 To 
detect the occurrence of events in geo¬ 
graphically distant processes, an observ¬ 


er must receive a “notification” mes¬ 
sage. Because of unpredictable propa¬ 
gation delays, the arrival times of these 
notifications may bear no resemblance 
to the order in which the events origi¬ 
nally occurred. Time-stamping the no¬ 
tifications at their source with the cur¬ 
rent real time is also unhelpful, even 
when the local real-time clocks are close¬ 
ly synchronized, because the real-time 
ordering of events may be affected by 
CPU loads unrelated to the computa¬ 
tion of interest. The perceived ordering 
of events based on these time stamps 
may be merely an artifact of relative 
processor speeds, with no significance 
for the computation itself, and may be 
different each time the same computa¬ 
tion is performed. 

In the past, a popular approach to this 
problem was to time-stamp events us¬ 
ing so-called Lamport clocks (totally 
ordered logical clocks). 1 Unfortunate¬ 
ly, these time stamps impose on unre¬ 
lated concurrent events an arbitrary 
ordering that the observer cannot dis¬ 
tinguish from genuine causal relation¬ 
ships. 

Time-stamping the event notifications 
with partially ordered time readings 
resolves all the debugging problems. 
The observer receives an accurate rep¬ 
resentation of the event orderings, can 
see all causal relationships, and can de¬ 
rive all possible totally ordered inter¬ 
leavings. Most importantly, the tech¬ 
nique greatly reduces the number of 
tests required. It is never necessary to 
perform the same computation more 
than once to see whether different event 
orderings (interleavings) are possible. 2 

Partially ordered logical clocks have 
been used experimentally for the detec¬ 
tion of global conditions in a homoge¬ 
neous network of processors, 8 for two 
prototype implementations of a moni¬ 
tor for Ada programs, 5 and for a proto¬ 
type temporal assertion checker for 
Occam. 2 

Definition of global states. The “hap¬ 
pened before” relation provides for 
straightforward definitions of normally 
subtle concepts. For instance, a “cut” of 
a distributed computation partitions the 
events performed into two sets: “past” 
and “future.” In a consistent cut, the set 
of past events C does not violate causal¬ 
ity; for example, it does not contain the 
reception of a message without its trans¬ 
mission. This concept has a very simple 
definition in terms of partially ordered 


time. 3 Assume that E represents the set 
of all events performed during a com¬ 
putation using only asynchronous mes¬ 
sage-passing. Then a consistent cut C is 
a finite subset Cc£such that 

Ve: E; c: C ■ (e -> c) => (e e C) 

In other words, if any event e “hap¬ 
pened before” an event c in the cut set 
C, then e must also be in the cut set. 

This is an important concept in the 
theory of distributed error recovery and 
rollback. Consider a distributed system 
consisting of a static number of non¬ 
nested processes, each of which peri¬ 
odically stores a “snapshot” of its local 
state (including the contents of mes¬ 
sage queues). If a set of snapshot events 
S c C, one from each process, forms 
the leading edge of a consistent cut C, 
that is, 

Vs: 5; c:C--,(s->c) 

then these local states form a valid glo¬ 
bal state from which an erroneous com¬ 
putation may be restarted. 

Partially ordered time has also been 
used in the analysis of other global state 
problems, for instance, characterization 
of distributed deadlocks. 9 


Concurrency measures. A concurren¬ 
cy measure is a software metric that 
objectively assesses how concurrent a 
computation is. It measures the struc¬ 
ture of the computation graph, rather 
than elapsed execution time. Partially 
ordered logical clocks have proved im¬ 
portant in the definition and proposed 
implementations of such measures. 

One of the simplest such measures, 
known as co, counts the number of con¬ 
current pairs of events that occurred 
during the computation and divides this 
by the total number of pairs of events 
between processes. 10 For a given com¬ 
putation C, consisting of two or more 
nonnested processes, the measure is 


co(C) = 


| {{ e i’fj) :e i co fj} | 


where the relation “co” is true between 
two distinct events if and only if they 
cannot causally affect one another, that 
is, 


e, co fj o (e, ^ fj) a i(fj > e t ) 
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Charron-Bost 10 has defined a more 
discerning measure, m, using consis¬ 
tent cuts: 


The value p represents the number of 
consistent cuts that occurred during the 
computation, q 1 is the number of con¬ 
sistent cuts that would be possible if the 
computation consisted of only one pro¬ 
cess, and fi c is the number of consistent 
cuts possible if causal relationships due 
to interprocess communication are ig¬ 
nored. 

Because both to and m are defined in 
terms of the “happened before” rela¬ 
tion, they can both be implemented by 
time-stamping all events with partially 
ordered time readings for postmortem 
analysis. Elsewhere I have investigated 
measures that allow for process¬ 
nesting or can be evaluated efficiently 
at runtime. 11 

Enforcement of causal ordering. The 

“causal ordering” abstraction, which 
prevents asynchronous message over¬ 
taking, has applications in several ar¬ 
eas. 12 For management of replicated 
data in distributed databases, it can be 
used with a “write-enabling” token 
model to ensure that updates are ap¬ 
plied in the same order at all sites. 
When monitoring activity in distribut¬ 
ed systems, it ensures that all observers 
receive notification of events in the 
same order. Also, in the allocation of 
shared resources, causal ordering guar¬ 
antees that servers honor requests in 
the order that they were made, rather 
than received. 

The rule required for enforcement of 
causal ordering is easily defined in terms 
of “happened before.” 12 For two send 
events e, and f p where both messages 
are received by process p k as events g k 
and h k , respectively, we need to guar¬ 
antee that 

0 , -*fj) => (g k -* K) 

A possible implementation of this 
rule using vector time (for computa¬ 
tions without process-nesting) involves 
piggybacking control information on 
each outgoing message m, so the desti¬ 
nation process knows whether there 
are other messages in transit that it 
must receive before it can accept m. n 
The piggybacked information consists 
of a bounded number of destination- 


site/vector-time pairs representing mes¬ 
sages known to be in transit to the des¬ 
tination process. A destination process 
must not accept a message until all the 
message’s time stamps “happened be¬ 
fore” the current local time. 


P artially ordered logical clocks are 
a fundamental new approach to 
the analysis and control of com¬ 
putations performed by distributed 
computing systems. They accurately 
reflect causality and are unperturbed 
by the random influences of system load, 
relative processor speeds, and different 
system configurations. In testing and 
debugging, they greatly reduce the num¬ 
ber of tests required by simultaneously 
presenting any observer with all possi¬ 
ble interleavings of events. Both their 
theory and practical application are 
now well established, but we will see 
further progress in both areas in the 
near future. ■ 
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The Galaxy Distributed 
Operating System 
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Hyo Ashihara, Naoki Utsunomiya, Kyu S. Park, and Hirohiko Nakano 
University of Tokyo 


J udging from the enormous amount of distributed-system research car¬ 
ried out over the past decade, information processing experts have come 
to recognize the advantages these systems possess. These research activ¬ 
ities have led to the availability of more than 50 network and distributed 
systems. However, most of these systems can only partially succeed in attaining the 
major goals of a distributed system, which include transparency, higher perfor¬ 
mance, higher reliability and availability, and higher scalability. Of course, attain¬ 
ing all these goals in the first attempt is impossible. 

Nonetheless, gradual improvements are possible by learning from existing 
systems and trying to overcome their limitations. The University of Tokyo’s 
Galaxy research project attempts to design, implement, and use a distributed 
computing environment based on this idea. 


Analyzing why existing 
distributed systems are 
limited, the Galaxy 
research project 
borrows many concepts 
and proposed facilities 
and integrates them 
with its own novel 
design features. 
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Design goals and novel aspects 

In designing Galaxy, our primary goal was to build a distributed operating 
system suitable for use in both local and widearea network workstations. To 
achieve this goal, we eliminated the use of broadcast protocols in any of our 
mechanisms, avoided the use of global-locking or time-stamp-ordering mecha¬ 
nisms while maintaining the consistency of replicated information, and decentral¬ 
ized the management of all globally useful information. 

Our second major goal was to ensure high performance. Design decisions and 
novel system features that helped us achieve this goal include 

• developing the Galaxy kernel from scratch, rather than modifying an existing 
Unix kernel; 

•using multiple-level interprocess communication mechanisms to meet the 
various communication needs of different applications; 
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Figure 1. Galaxy’s layered system structure. 


• employing the concept of variable- 
weight processes to allow flexibility and 
efficiency in data sharing and process 
scheduling; and 

• inventing an ID-table-based direct 
object locating mechanism. 

Our next major goal is higher reliabil¬ 
ity and availability. Our direct object 
locating mechanism, user-definable re¬ 
liability parameters for name resolu¬ 
tion operation, use of data caches and 
name caches, and file replication mech¬ 
anism help in improving our system’s 
overall reliability and availability. 

Another of our design goals is to make 
Galaxy’s application interface compat¬ 
ible with that of Unix. To this end, we 
first designed the best interface from 
the viewpoint of distributed operating 
systems and then properly modified it 
to make it a superset of the present 
Unix interface. In addition, to achieve 
this goal, and as long as other goals did 
not suggest using any special techniques, 
we modeled our system as closely as 
possible to Unix. 

Galaxy system 
architecture 

The Galaxy design belongs to the serv¬ 
er-pool class of systems, with an under¬ 
lying computational model based on 
objects. We had two main reasons for 
adopting the server-pool approach. First, 
Galaxy’s design allows for the existence 
of diskless workstations in the network. 
This design issue precludes the use of an 
integrated system approach in which 
each node of the network is an autono¬ 
mous, stand-alone system. Our second 
reason is our design policy of placing a 
particular module of the system only on 
those nodes of a network where there is 
some possibility of using it. Blindly 
maintaining all system utilities at every 
node appears to waste various system 
resources. 

Galaxy objects. In Galaxy, the entities 
that need to be identified at the operating 
system level (such as processes, files, de¬ 
vices, and nodes) are viewed as objects. 
Every object in Galaxy belongs to a par¬ 
ticular type. A type describes a set of 
objects with the same characteristics. A 
type also describes the structure of data 
carried by objects as well as the opera¬ 
tions (methods in the object-oriented ter¬ 


minology) applied to these objects. Users 
of a type see only the interface of the type, 
that is, a list of methods together with 
their signatures (the type of input param¬ 
eters and the type of the result). 

In Galaxy, each type of object is man¬ 
aged by a special module dedicated to 
the type. We call this module the object 
manager. A particular type of object 
manager resides on all the nodes where 
objects of that type exist. When an op¬ 
eration invocation message is issued to 
an object, the corresponding object 
manager is invoked. 

This object management policy has 
several attractive features: 

(1) It ensures that access to managed 
resources (objects) is efficient, because 
the manager and the managed object 
reside on the same node. 

(2) It ensures that the presence of an 
object manager at a particular node is 
not wasteful. 

(3) It eases the problem of coping 
with hardware failures since, for exam¬ 
ple, if a node crashes, the managers for 
all the objects of that node will also be 
unavailable. 

(4) It is easily adaptable to different 
hardware configurations. 

System structure. One of the most im¬ 
portant issues in designing the structure 
of a distributed operating system is the 
size of the kernel that is replicated at each 


node of the network. In a large-kernel 
approach, taken by such systems as Lo¬ 
cus 1 and Sprite, 2 services are provided 
more efficiently than in cases where they 
are offered outside the kernel. However, 
this approach reduces the overall flexibil¬ 
ity and configurability of the resulting 
operating system. 

In a small-kernel approach, taken by 
V, 3 most of the services are executed by 
separate servers. The servers are usually 
implemented as processes and can be 
programmed separately. A small kernel 
provides the process scheduling, inter¬ 
process communication, and some other 
primitive operations. This approach ac¬ 
complishes the maximum flexibility, but 
it degrades efficiency. 

In Galaxy, we use the small-kernel 
approach. For the sake of efficiency, we 
structure our system in multiple levels 
with various communication facilities 
between the processes of these levels. 
As Figure 1 shows, Galaxy features five 
levels: 

(1) the kernel level, 

(2) the device drivers level, 

(3) the local servers/managers level, 

(4) the network manager level, and 

(5) the user level. 

The kernel level, which is replicated 
on all the nodes, contains the most prim¬ 
itive functions of the system. These func¬ 
tions are implemented as procedures in 
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Figure 2. Galaxy’s three-level naming scheme. 


the kernel and can be classified into the 
following types: 

(1) interrupt-handling routines, which 
set commands to hardware and catch 
interrupt signals from hardware, 

(2) routines for handling the most 
primitive interprocess communications, 

(3) process-handling routines, which 
manage system structure for processes, 
save and restore process context, and 
perform process scheduling, and 

(4) memory management routines, 
which manage physical memory and 
perform read/write operations on the 
physical memory. 

The device drivers level consists of 
the device driver routines, including 
clock driver, disk driver, tty driver, and 
network driver. The availability of a 
particular routine of this level at a par¬ 
ticular node depends on the availability 
of the corresponding device on that node. 
The device drivers communicate with 
the kernel frequently by sending kernel 
input/output commands and respond¬ 
ing to the kernel’s interrupts. Thus, they 
share the address space with the kernel, 
so that they can access kernel data struc¬ 
ture and respond to the kernel faster. 
The routines in the kernel level and the 
device drivers level run in privileged 
mode. 

The routines at the local servers/man¬ 
agers level perform local object man¬ 
agement. For example, the file manager 
routine is responsible for handling the 
local files, the process manager routine 
is responsible for handling the local pro¬ 
cesses, etc. The ID manager routine of 
this level provides the location of a re¬ 


mote object for the realization of loca¬ 
tion-independent object accessing in our 
system. 

The routines at the network manager 
level perform networkwide object man¬ 
agement. Networkwide virtual memory, 
object migration, object replication, and 
the like are realized at this level. Most 
modules at the local servers/managers 
level and the network manager level are 
implemented as processes that have sep¬ 
arate address spaces. 

The user level provides services such 
as object naming, user management, and 
implementation of object-based envi¬ 
ronment. The modules at this level are 
implemented as distributed servers; they 
can be located at any node, and their 
programs are location independent. Oth¬ 
er modules at this level are implement¬ 
ed as local servers, but a user can invoke 
both categories of modules by using the 
same interprocess communication fa¬ 
cility. 

Object naming and 
locating 

In designing Galaxy’s object-naming 
and object-locating mechanisms, we 
were particularly concerned about trans¬ 
parency, scalability, reliability, and effi¬ 
ciency issues. To satisfy the transparen¬ 
cy requirement, we used the single global 
name space model used by such recent 
distributed systems as Locus, 1 V, 4 and 
Sprite, 5 because it supports location 
transparency of both request-receiving 
objects and request-issuing objects. 

Direct mapping of a user-defined ob¬ 


ject name to the object’s location every 
time the object is accessed will require 
the name resolution operation to be 
carried out for every access to the ob¬ 
ject, which will degrade efficiency. More¬ 
over, user-defined names are not unique 
for a particular object and are variable 
in length, not only for different objects 
but even for the different names of the 
same object. Hence, they cannot be eas¬ 
ily manipulated, stored, and used by the 
machines for identification. Therefore, 
in addition to user-defined hierarchical 
names, which are useful for the users, 
Galaxy employs system-defined flat 
names that can be used efficiently by 
the system. 

In Galaxy, user-defined names are 
called external names, and system- 
defined names are called unique identifi¬ 
ers (ID for short). As Figure 2 shows, an 
external name is first mapped to its cor¬ 
responding ID, which in turn is mapped 
to the physical locations (node numbers) 
of the replicas of the concerned object. 
The Galaxy process of mapping an exter¬ 
nal name to its corresponding ID is called 
name resolution, and the process of map¬ 
ping an ID to the physical locations of 
the replicas of the concerned object is 
known as object locating. 

The object-locating mechanism. The 

general requirement for object locat¬ 
ing is a mapping table (called ID table 
in Galaxy), each entry of which con¬ 
sists of the locating information of an 
object. In particular, a Galaxy ID-ta- 
ble entry (or IDTE) contains informa¬ 
tion about the type of the object, an 
access control list for the object, loca¬ 
tions of the object’s replicas ( replica 
list), and locations where the copies of 
this IDTE exist ( copy list). 

The replica list helps in returning all 
the locations of the desired object as a 
result of the object-locating operation. 
Using the copy list, all IDTEs of the 
same object are linked together so that 
any modification can be consistently 
made to all copies. 

Thus, given an object’s ID, its physi¬ 
cal location can be known simply by 
searching the given ID in the ID table 
and extracting the physical locations of 
its replicas from the ID table. However, 
the most difficult facet of the locating 
mechanism is the decision policy for 
maintaining this mapping table. 

Several methods have been pro¬ 
posed and used in existing distribut¬ 
ed systems: 
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• the method of broadcasting, 

• the method of hint cache and broad¬ 
casting, 

• the method of chaining, 

• the centralized server method in 
which the entire ID table is kept on 
a single node, and 

• the full replication method in which 
the entire ID table is replicated on 
all the nodes 

However, all these mechanisms suf¬ 
fer from one or more of the common 
limitations of poor efficiency, poor reli¬ 
ability, and poor scalability. 

Galaxy uses a totally different ap¬ 
proach to overcome the limitations of 
the existing mechanisms. On a particu¬ 
lar node, Galaxy keeps only the locat¬ 
ing information for objects that have 
some possibility of being accessed from 
the concerned node. To achieve this, we 
determined that in Galaxy only the fol¬ 
lowing two categories of IDs are neces¬ 
sary in the ID table of a particular node: 

(1) IDs contained in a directory or in 
a name cache of that node. The pres¬ 
ence of these IDTEs in the local ID 
table of a node is necessary for the 
direct locating of the directory file ob¬ 
jects during the name resolution pro¬ 
cess. 

(2) IDs being used by the processes 
running on the node. These IDTEs are 
necessary in a node’s ID table for the 
direct locating of the objects being used 
by that node’s processes. 

Based on this idea of direct-object 
locating and our object management 
policy discussed in the section entitled 
“Galaxy objects,” a process accesses a 
remote object as illustrated in Figure 3. 
This approach enjoys the advantages of 
very high efficiency, reliability, and seal- 
ability of the object-locating operation 
because any object can be located di¬ 
rectly by using the locating information 
stored in the local node without the 
need to replicate the entire ID table on 
all the nodes. 

We determined the following 
primitives to be sufficient for IDTE 
management: ReadIDTE (ID,field), 
Insertltem(/D, field, item), and 
Deleteltem(/D, field, item). We ob¬ 
served that each IDTE is a collection of 
fields and that each field can be updated 
incrementally as well as independently. 
We also found that the two update op¬ 
erations Insertltem and Deleteltem are 


commutative operations; that is, the fi¬ 
nal result produced by a sequence of 
these update operations does not de¬ 
pend on the order in which the opera¬ 
tions are executed. 

The execution order of the two up¬ 
date operations should be serialized only 
when two update operations are per¬ 
formed on the same item in the same 
field of the same IDTE. These proper¬ 
ties made it possible to design an update 
mechanism on replicated IDTEs with 
high concurrency and efficiency. 

In this mechanism, read and update 
operations are done directly to the local 
replica of the ID table. The system exe¬ 
cutes an update operation issued by a 
local user on the local replica and re¬ 
turns control to the user immediately. 
The update operation is propagated lat¬ 
er to other nodes holding a replica, with 
no need of synchronization. 

To allow updates to an IDTE even 
during the creation of a new replica of the 
IDTE, we define the node that makes a 
new replica of an IDTE at another node 
to be the parent of the newly created 
replica. The node in which the parent 
resides must keep informing the other 
replicas of the IDTE until they all come 
to know about the newly created replica. 
The access consistency is checked when 
the location information in an IDTE is 
used to locate the corresponding object. 

Compared with other concurrency and 
consistency control mechanisms that 
guarantee strict consistency among rep¬ 
licas of data, our approach has the fol¬ 
lowing characteristics: 

(1) neither global locking nor time- 
stamp ordering is required, 

(2) updating operations can be issued 
and executed without being synchro¬ 
nized, and 


(3) accesses to directories are allowed 
even during insertion of a new object 
replica or an IDTE replica as well as 
during the deletion of an object replica 
or an IDTE replica. 

Jia et al. 6 discuss the correctness and 
applicability of the algorithm. 

The name resolution mechanism. In 

conventional operating systems, direc¬ 
tories are used to map an object’s name 
to its physical location. In these sys¬ 
tems, a directory entry consists of a 
component name and the corresponding 
object descriptor pointer, such as i-nodes 
in Unix 7 and v-nodes in the Sun NFS. 8 
Galaxy differs from those systems in 
that a Galaxy directory entry is a (com¬ 
ponent name, ID) pair that maps a com¬ 
ponent name of an object to its system- 
wide unique ID. In addition, in Galaxy, 
name caches are used at each node for 
caching recently used directory entries. 
Like the directories, Galaxy’s name 
caches are hierarchical in structure. 
Using the name cache and the directory 
objects, the name resolution operation 
is performed by the basic method of 
remote pathname expansion. 9 

In the remote pathname expansion 
mechanism, the reliability of resolving 
a pathname from a particular node is 
greatly influenced by the locations of 
the directories or their replicas that cor¬ 
respond to the given pathname compo¬ 
nents. On the basis of the various possi¬ 
ble locations of the replicas of the 
concerned directories, we define the 
following factors that influence the reli¬ 
ability of the name resolution opera¬ 
tion: 

(1) Subpath: For a (node, pathname) 
pair, the subpath reliability of the name 
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Figure 4. Typical examples of name resolution reliability factors while locating 
an object with pathname /a/b/c: (a) values of reliability factors are subpath =/, 
m-stage = 2, A-path = 1; (b) values of reliability factors are subpath = /a, m- 
stage = 1, A-path = 1; (c) values of reliability factors are subpath = /a/b, m-stage 
= 0, A-path = (d) values of reliability factors are subpath = /, m-stage = 2, A- 

path = 1; (e) values of reliability factors are subpath = /, m-stage = 2, A-path = 2. 


resolution operation is the presence of 
the necessary directories on the client 
node (specified node) for tracing the 
components of the pathname up to the 
subpath right at the client node without 
communicating with any other node. 

(2) m-stage: A name resolution oper¬ 
ation is said to be m-stage unreliable 
when m hops are required during path¬ 
name expansion for resolving the given 
pathname. In our method of remote 
pathname expansion, a hop is defined 
as the passing of the remaining path¬ 
name components from one node to 
another node, which has the next com¬ 
ponent’s directory when the remaining 
components of the pathname cannot be 
further resolved on the present node. 


(3) k-path: A name resolution opera¬ 
tion is said to be A-path reliable when 
there are at least A possible paths be¬ 
tween any two contiguous directories 
corresponding to the components of the 
given pathname starting from its root 
directory to the last directory of the 
given pathname. Note that the term path 
here means the logical name resolution 
path (path of the pathname from one 
directory to another) and not the phys¬ 
ical path of the network. 

Figure 4 shows some typical examples 
of these three reliability factors. The bro¬ 
ken lines in this figure indicate a message 
transfer for object accessing and not for 
name resolution. Hence, the broken lines 


are not taken into account for the name 
resolution reliability factors. Using the 
reliability parameters mentioned above, 
a Galaxy user can specify reliability re¬ 
quirements for the various (node, exter¬ 
nal name) pairs of interest. 

Depending on the users’ specifica¬ 
tions, the system automatically repli¬ 
cates the necessary directories at the 
proper nodes. This approach seems log¬ 
ical because all the objects in a system 
are not of equal importance to all users 
and a particular user normally works at 
only a few nodes of a large distributed 
system. Using this approach, it is possi¬ 
ble to give users the degree of reliability 
they want for resolving various names 
without greatly affecting the overall sys¬ 
tem efficiency. 

Interprocess 

communication 

The interprocess communication 
(IPC) facility has several uses in a sys¬ 
tem, including informing processes of 
asynchronous event occurrences, re¬ 
questing processes to perform opera¬ 
tions, and transferring data from one 
process to another. Thus, using a single 
IPC mechanism for handling all types of 
uses and for communicating among the 
processes at all different levels of the 
system structure will be very inefficient. 
This inefficiency relates to the amount 
of data to be transferred, the timing 
constraints, etc., which are normally 
different for all these cases. 

Based on this observation, Galaxy 
provides different types of IPC facili¬ 
ties, giving users the flexibility to choose 
and use the most suitable facility for 
their specific application needs. Below, 
we discuss the various types of IPC 
mechanisms provided in Galaxy. 

Interrupt message passing. A user 
explicitly wanting to avoid waiting for 
messages can trigger a software inter¬ 
rupt when the message is received. The 
interrupt service routine, executed in 
the context of that process, can then 
receive the incoming message and pro¬ 
cess it, or it can notify the main program 
of the event in a user-defined manner. 
A mechanism like this can allow pro¬ 
cesses that are inherently bound to com¬ 
putation to react quickly to incoming 
messages without using some form of 
message polling. It can also be used to 
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Figure 5. Network-transparent interprocess communication mechanism. 


trigger language-defined exceptions 
across process boundaries. 

Fixed-size message passing. Galaxy 
supports three types of communication 
facilities in this category: 

(1) Blocking type: This type of facil¬ 
ity can be used to implement IPC that, 
to the sender, looks like a procedure 
call. Just as a procedure caller passes on 
control to the procedure, so our sender 
yields to the receiver. The send request 
message passes the equivalent of proce¬ 
dure arguments, and the reply message 
returns the results. 

(2) Asynchronous type: In this case, if 
the destination process is waiting for 
the message, the message is sent out; 
otherwise, control is returned immedi¬ 
ately to the sender, and the request is 
recorded as an event. When the destina¬ 
tion process receives the message, an 
interrupt to the sending process is exe¬ 
cuted. A similar scheme is used for an 
asynchronous receive. 

(3) Polling type: Here, if the destina¬ 
tion process is not ready to receive the 
message, control is immediately returned 
to the sender. In contrast to what hap¬ 
pens in the asynchronous type, the re¬ 
quest is not recorded; hence, there is no 
trace of the message. If the process 
“wants” to send the message later, the 
sender has to repeat the poll to ascer¬ 
tain whether the receiver is ready to 
receive the message. A similar scheme 
is used for a polling receive. 

Message passing by memory sharing. 

Galaxy uses two memory-sharing ap¬ 
proaches for IPC: 

(1) Virtual page transfer: Here, when 
a page of data is sent from a source 
process to a destination process, the 
system modifies the page table of the 
source process to detach the page from 
the source process, and the page table 
of the destination process points to that 
page. The page data is neither copied 
nor moved to another place. The sender 
and the receiver should be synchronized 
for the page transfer. This mechanism is 
especially useful for transferring I/O 
buffers among the file servers, the de¬ 
vice drivers, and the users. 

(2) Segment sharing: In this method, 
data sharing is implemented by chang¬ 
ing the mapping of virtual memory. After 
a source process sends a segment of 
data to a destination process, both pro¬ 


cesses can access the data. Two process¬ 
es that want to share a memory segment 
must synchronize with each other. 

Networkwide IPC. In Galaxy, any IPC 
command finally causes a trap to enter 
kernel processing. The kernel searches 
the local process table for the receiver 
process of a communication. If the re¬ 
ceiver is at the local node, it handles the 
communication locally; otherwise, the 
IPC request is forwarded to a special 
user-level module called the message 
server. 

The message server locates the re¬ 
ceiver by interacting with the ID man¬ 
ager and forwards the request message 
to the message server of the node on 
which the receiver resides. The request 
is serviced at the receiver’s node, and 
the result is returned to the sender via 
the message servers of the two nodes. 

Thus, when a sender transmits a mes¬ 
sage to a receiver, the sender has no 
direct means of determining whether the 
receiver is local to its node or is actually 
on a remote node. Hence, our IPC mech¬ 
anism is network transparent, and the 
primitives for local as well as remote 
message passing are the same. Figure 5 
illustrates our network-transparent IPC 
mechanism. 

Computation model 

Concurrent processing is one of the 
key concepts for achieving greater effi¬ 
ciency in the present computing era. 
The desirable properties of the process 
management mechanism of a system 
with concurrent processing include low 
overhead in process creation, deletion, 


and context-switching operations; flex¬ 
ible and efficient information sharing 
among the processes; and flexibility for 
users to define their own process sched¬ 
uling policies. 

In conventional operating systems, 
current solutions for these requirements 
are the concepts of light-weight pro¬ 
cesses and coroutines in process man¬ 
agement. 10 However, because of their 
own limitations, neither light-weight 
processes nor coroutines are suitable 
for the needs of current and future par¬ 
allel computing. 

For example, the concept of light¬ 
weight activities has limited applicabil¬ 
ity for various reasons. These include 
the inability to support a large number 
of processes; the fairly large overhead 
involved in process creation, deletion, 
and context-switching operations; the 
lack of user flexibility to control sched¬ 
uling and other aspects of processes; 
and the difficulty of distributing light¬ 
weight processes on the various nodes 
of a distributed system with no shared- 
memory facility. 

Similarly, coroutines suffer from de¬ 
ficiencies such as lack of true parallel¬ 
ism, poor inter-coroutine communica¬ 
tion facilities, lack of a mechanism to 
protect coroutines from each other if 
required, and the inability to distribute 
coroutines over different nodes of a 
distributed system. Furthermore, at 
present, concurrent processing capabil¬ 
ities provided by operating systems, 
distributed systems, and language sys¬ 
tems are isolated and are not under a 
uniform interface. This makes it diffi¬ 
cult to write programs that contain var¬ 
ious types of processes and interactions 
among them. 
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Based on these observations, we real¬ 
ized that to fulfill the various applica¬ 
tion needs, an ideal process manage¬ 
ment mechanism should provide a 
variety of processes whose properties 
vary. We thus proposed the notion of 
variable-weight processes in Galaxy. 

Weight is defined as the amount of 
resources owned and accessed by a pro¬ 
cess. The amount of the resources is 
measured in two dimensions: space and 
time. Variable-weight processes allow a 
program to use a suitable set of pro¬ 
cesses with different weights. Further¬ 
more, a generic interface can be provid¬ 
ed for a suitable weight of processes to 
be chosen at loading time or even at 
runtime. 

Executor/domain model. To meet flex¬ 
ibility, efficiency, and parallelism com¬ 
puting requirements and support vari¬ 
able-weight processes, we have proposed 
a new computation model called Execu¬ 
tor/domain. An executor is an active en¬ 
tity that either owns or has access rights 
to domains. A domain is a unit of infor¬ 
mation identifiable by its name. 

For example, one or more pages of a 
file may form a domain. The set of do¬ 
mains either owned or accessed by an 
executor is called the executing domain 
of the executor. The set of domains 
common to two executors is said to be 
shared by the two executors. Since the 
executing domain is arbitrarily defined 
for each executor, the shared domains 
can be flexibly defined for a group of 
executors. 

An executor itself is described by a 
data structure called an executor descrip¬ 
tor, which is also maintained in some 
domains. The descriptor specifies the 
detailed information (such as registers 
and stack area) for its execution. If de¬ 
sired, the user can select a bare CPU as 
the executor or choose a fully equipped 
process—a process with its address space 
and all other necessary resources. This 
structure is flexible and enables a user to 
choose variously weighted processes for 
job execution. 

Executor scheduling is primarily a 
function of the operating system’s ker¬ 
nel, but in some cases, enabling the user 
to write the scheduler is desirable. Gal¬ 
axy allows user scheduling at the 
light-weight-process level. Most sched¬ 
uling of light-weight processes is con¬ 
trolled by user-defined schedulers. The 
kernel supports only the operations of 
catching interrupt signals, access con¬ 


trol, switching execution mode, etc., and 
this makes the kernel very light. 

Hybrid approach for light-weight ac¬ 
tivities. Conventional operating systems 
take two approaches to implementing 
light-weight processes or threads: in¬ 
kernel implementation and out-of-ker- 
nel implementation. 

In in-kernel implementation, the ker¬ 
nel performs scheduling; therefore, par¬ 
allelism and preemption are given by 
the kernel scheduler. Potential addi¬ 
tional cost is a serious concern with this 
approach. A trap or system call is neces¬ 
sary to cross the user process/kernel 
protection boundary when these opera¬ 
tions are executed. In addition, the ker¬ 
nel must maintain the management data 
in its virtual address space. 

On the other hand, coroutine packag¬ 
es are widely used in out-of-kernel im¬ 
plementation of light-weight processes. 
We discussed their disadvantages above. 
Moreover, making a coroutine preemp¬ 
tive requires extra cost. 

To overcome these limitations, Gal¬ 
axy uses a hybrid approach for imple¬ 
menting light-weight activities. Galaxy 
features two classes of light-weight ex¬ 
ecutors: 

(1) user-mode kernel-supported ex¬ 
ecutors and 

(2) user-mode executors in a single 
kernel-supported base executor. 

One or more user-mode executors can 
be defined within each kernel executor. 
They share the whole address space of 
the kernel-supported base executor, 
which is defined by the domain to which 
the kernel executor is attached. 

A kernel-supported user-mode exec¬ 
utor, known as a microprocess, is an 
executor whose runtime context is main¬ 
tained in the user address space; sched¬ 
uling is performed in the user mode. 
However, in this class of executors, the 
kernel provides a clock-handling facil¬ 
ity for creating preemptive executors. 
By sharing the address space with a 
kernel, the system call for the clock 
handling is executed with a small over¬ 
head. 

In addition, the two classes of user¬ 
mode executors have the following spe¬ 
cial features: 

(1) If a user-mode executor takes a 
page fault or another kind of trap, other 


user-mode executors within the same 
kernel executor can continue their exe¬ 
cution. 

(2) User-mode executors can issue 
distinct system calls and I/O requests. 

(3) User-mode executors can be de¬ 
fined hierarchically; the scheduling is 
performed at each level of the user¬ 
mode executor hierarchy. This facility 
is especially useful for implementing 
hierarchical objects in an object- 
oriented environment. 


G alaxy is still under development, 
and extensive performance com¬ 
parisons with other systems have 
not yet been undertaken. But, our expe¬ 
rience to date indicates that Galaxy’s 
design is fundamentally sound, although 
some refinement and further efforts are 
necessary in a number of areas. 

As of this writing, prototypes of ma¬ 
jor system components have been im¬ 
plemented. All but a few hundred lines 
of code are written in C, with the re¬ 
maining lines written in assembly lan¬ 
guage. Galaxy runs on IBM RT/PC 
workstations. 

The prototype implementations have 
demonstrated the viability and attrac¬ 
tiveness of individual components. The 
full system is being implemented, and 
we are conducting experiments to mea¬ 
sure the performance of each system 
component. 

We plan to continue Galaxy research 
in the future in areas given low priority 
while we were setting our design goals. 
The areas include supporting a network 
of heterogeneous nodes, supporting re¬ 
sistance to maliciousness, and support¬ 
ing real-time applications. ■ 
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Distributed computing, 
like anything else, 
profits from good 
management. Here, we 
discuss the issues of 
managing distributed 
applications and 
present a set of tools 
that solves some long¬ 
standing problems. 


A program that performs correctly differs greatly from one that performs 
well. The former simply operates without failure and produces correct 
results, while the latter also uses resources efficiently and behaves pre¬ 
dictably over a range of environmental and operating parameters. Writing distrib¬ 
uted programs that perform well is especially difficult. These programs may run in 
widely varying configurations — from a single machine to tens or hundreds — and 
on machines with different performance levels or vendors. Often the programs 
must continue to operate when some machines have failed. 

We call the activity of producing a distributed program that performs well in a 
given environment distributed application management. It involves 

• configuring the system components for a given hardware and software envi¬ 
ronment, 

• initializing the application in an orderly way, 

•monitoring the application’s behavior and performance, and 
• scheduling work efficiently among the components. 

An application must be managed throughout its execution because the system 
must continually react to varying work loads, environment changes, and failures. 

Traditionally, application management is performed manually or hardwired 
into the application code. A person thoroughly familiar with the application must 
continually monitor and control it; some adaptations can be made only by repro¬ 
gramming. In practice, many aspects of application management are ignored, 
which results in poorly engineered systems that usually work but often exhibit 
unpredictable performance, become inconsistent, expose partial failures, and 
prove fragile when small changes are made to the hardware or software base. We 
seek to avoid the deficiencies of this ad hoc approach by creating a framework 
favoring the construction of robust distributed management software and applica¬ 
tions. We have also developed a set of tools — the Meta system — that directly 
supports our approach. 

A distributed computing environment causes more problems for application 
management than a nondistributed environment. The performance data required 
for system monitoring is distributed throughout the system, making it hard to 
access. Variable communication delays produce less-than-accurate data that is 


42 


0018-9162/91/0800-0042501.00 © 


IEEE 


COMPUTER 




Other 

commun¬ 

ication 


■ 4 ". 


^-f—H 

T Meta : ' ! 

! system 1 

t-f 


H 


Hardware and operating system 


Actuators 
v Sensors 


Figure 1. Meta application architecture. 


difficult to collate. The po¬ 
tential for improved perfor¬ 
mance through concurren¬ 
cy is attractive, but this 
concurrency significantly 
complicates all aspects of the 
application. For instance, 
components must be initial¬ 
ized in a well-defined order 
that observes the dependen¬ 
cies between them. 

Failures are a fact of life 
in distributed systems and 
greatly complicate manage¬ 
ment. Most applications do 
not have strong reliability 
requirements, but unless 
special efforts are taken, the 
overall reliability of a distributed pro¬ 
gram will be much lower than that of 
some equivalent nondistributed pro¬ 
gram. Failure frequency directly relates 
to the number of hardware components. 

Additional problems arise when ex¬ 
isting nondistributed programs are re¬ 
used in a distributed program. Although 
this is an important way of reducing 
costs, the application often does not 
perform well and may be difficult to 
manage. For example, the dependen¬ 
cies among reused components may be 
poorly defined, making program start¬ 
up and recovery difficult. In addition, 
the kinds of internal state information 
necessary for performance monitoring 
and resource scheduling may not be 
made available by programs that were 
originally designed for nondistributed 
applications. The Meta approach is well 


suited to applications that reuse soft¬ 
ware in this way. 

We use the term application program 
to mean a distributed application com¬ 
posed of one or more processes. A pro¬ 
cess is a single nondistributed address 
space (as occurs in Unix) with one or 
more control threads. A component is a 
subsystem of the overall application that 
comprises one or more processes. We 
occasionally use the last term to refer to 
an environmental component such as a 
file server or a workstation. 

Application 

architecture 

Figure 1 depicts the Meta model of a 
distributed application. The application- 


management aspects are sep¬ 
arated from its major func¬ 
tional parts, and the interface 
between these two layers is 
well defined. Separating pol¬ 
icy from mechanism in this 
way makes modifying the 
management of an applica¬ 
tion easier and is less likely to 
impair the correctness of the 
rest of the program. 

We call the management 
layer the control program. 
While the underlying appli¬ 
cation is built with conven¬ 
tional programming tools, the 
control program is best writ¬ 
ten in a reactive rule-based 
style. The Meta system is interposed 
between the control program and the 
application, and presents the control 
program with an abstract view of the 
application and the environment in 
which it runs. (As Figure 1 shows, not all 
communication between the control 
program and the application need go 
through Meta.) The structure of the 
application program — its constituent 
components and their interconnections 
— is declared to Meta in the form of an 
object-oriented data model. 

The control program observes the 
application’s behavior through interro¬ 
gating sensors, which are functions that 
return values of the application’s state 
and its environment (see sidebar). Sim¬ 
ilarly, the behavior of the underlying 
application and its environment can be 
altered by using procedures called actu- 


Description of sensors and actuators 


Sensors 

The CPU utilization on a machine is a built-in Meta sensor. 
The load on an application component would equal the size 
of the component's input job queue. This user-defined sensor 
can be implemented by supplying a component procedure to 
calculate the value when needed, or by directly monitoring a 
variable in the process’s address space. 

The total throughput of the application would be computed 
by combining the data from a number of more primitive sensors 
located in each component. Meta provides ways to specify such 
derived sensors. 

The liveness of a component is determined by built-in sensors 
that test for the existence of a process or a user-defined sensor 
that implements an application-specific liveness criterion. 


Acuators 

Changing a process’s priority would occur through a 
built-in actuator that controls fine-grained scheduling. 

A lightweight thread’s priority would be changed by 
modifying a variable within a designated process’s ad¬ 
dress space or by invoking a user-specified procedure in 
a process. 

Migrating a process to another machine requires an 
operating system that implements process migration. 
Restarting a failed process involves selecting a ma¬ 
chine on which to restart a failed process, initializing the 
process, and integrating the new process into existing 
components. 
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ators. Meta provides a uniform, loca¬ 
tion-independent interface to both 
built-in and user-defined sensors and 
actuators. This interface also provides 
ways to combine multiple sensor values 
to compute more complicated sensors 
or provide fault tolerance. The particu¬ 
lar sensors and actuators that are used 
depend on the application being con¬ 
trolled. 

Meta offers several interfaces by which 
programs can query sensors and invoke 
actuators. The basic interface is from 
the application’s programming language. 
Other interfaces include our low-level 
postfix language NPL, which is execut¬ 
ed by a fault-tolerant distributed inter¬ 
preter, and our high-level control lan¬ 
guage Lomita, which is compiled into 
NPL expressions. Lomita combines real¬ 
time interval logic with a rule-based 
syntax for querying sensors. The se¬ 
mantics of Lomita cleanly captures the 
temporal nature of significant complex 
events in the distributed application. 
Although the Lomita implementation 
is not yet complete, we use it rather than 
NPL in the examples because it is easier 
to read. 

Meta uses the Isis distributed pro¬ 
gramming tool kit. 1 Isis provides prim¬ 
itives for reliable programming includ¬ 
ing process groups and ordered atomic 
multicast (sending a message to multi¬ 
ple destinations). On top of these prim¬ 
itives, Isis provides solutions to com¬ 
mon subproblems in distributed 
computing such as distributed syn¬ 
chronization, resilient computation, and 
logging and recovery. Meta and Isis ex¬ 
ecute on the Unix operating system. 

Seismological analysis 

To make our discussion of sensors 
and actuators more concrete, we present 
a hypothetical application and show how 
it is managed within the Meta frame¬ 
work. NuMon is a seismological analy¬ 
sis system for monitoring compliance 
with nuclear test-ban treaties. Science 
Applications International Corp. 2 de¬ 
veloped a real nuclear monitoring sys¬ 
tem, on which this simplified example is 
based, by using Isis and an earlier ver¬ 
sion of Meta that lacked NPL and Lo¬ 
mita languages. It was our experience 
with this project that motivated us to 
work on higher levels of Meta. 

NuMon consists of four component 
process types (see Figure 2). The SigPro 



Figure 2. Simplified seismological 
monitoring operation. 


processes (such as SigProl and SigPro2) 
collect seismological data and perform 
signal processing on it. The much small¬ 
er resulting processed data is stored in 
the DataStore. The Assess process is an 
interactive expert system that interprets 
the data produced by multiple SigPro 
processes and forms hypotheses about 
various events. To confirm these hy¬ 
potheses, further tasks are assigned to 
SigPro processes. Assess stores its event 
classifications in the DataStore. The 
structure of the real application is more 
complex, with several more kinds of 
SigPro processes that fit into the same 
framework. 

The AppManager contains the con¬ 
trol program for NuMon. During nor¬ 
mal operation the control program 
schedules work efficiently among the 
machines. When individual machines 
crash, it reapportions work automati¬ 
cally. When total failure occurs, it re¬ 
starts the application. 


AppManager. This program embod¬ 
ies the control policy for configuration, 
scheduling, and response to failures. This 
policy is expressed in the form of a rule 
base. Its second function is to support a 
graphical user interface that displays 
the current system state and lets users 
alter policy rules or issue commands to 
tune performance. Thus AppManager 
is semiautomatic. Common activities 
such as system startup and shutdown, 
and individual machine failures can be 
handled without human intervention. 
The user can handle other — perhaps 
unforeseen — circumstances. Typical 
examples include a persistent software 
error that causes some component to 
crash no matter how many times it is 
restarted. 


SigPro. These computation engines 
service requests from Assess and inter¬ 
active users, and process the input data. 
They derive from large sequential For¬ 
tran programs developed by seismolo¬ 
gists with little experience in distribut¬ 
ed programming. A crucial requirement, 
therefore, is that application-manage¬ 
ment functions can be easily added to 
these large programs without requir¬ 
ing substantial modification of Fortran 
code. 

To schedule work among these tasks 
and start auxiliary SigPro processes when 
needed to improve throughput, each 
SigPro exports two performance sen¬ 
sors: backlog and load. The backlog sen¬ 
sor measures the backlog of input data 
to be processed. It corresponds to a 
program variable in SigPro. The load 
sensor procedure returns a measure of 
SigPro load by combining load factors 
such as the current size of the input task 
queue and the recent activity within the 
process. 

The AppManager typically examines 
sets of sensor values, such as the aver¬ 
age of all SigPro load sensors or the 
maximum of a load sensor over the last 
2 minutes. These operations are direct¬ 
ly supported by Meta through the no¬ 
tion of derived sensors, which are com¬ 
puted from primitive sensor values using 
a number of built-in functions. 


Assess. This expert system executes 
at length and builds up considerable 
internal state, making fault tolerance 
important. If the Assess process fails 
(for example, the machine crashes), a 
new copy of Assess is started elsewhere. 
In order for this to occur, the AppMan¬ 
ager must monitor the Assess process, 
choose a new location to restart Assess 
after a crash, and reconnect this new 
process to the SigPro and DataStore 
subsystems. Then the work that was in 
progress must be assigned to the newly 
created Assess. 

AppManager uses Meta and Isis to 
accomplish these actions in a fault- 
tolerant manner. Assess uses the Isis 
message spooler to log its actions and to 
periodically “checkpoint” its state. In 
this way, AppManager leaves a stable 
record of the tasks it was engaged in 
should it fail. Some built-in Meta sen¬ 
sors detect failure and identify suitable 
alternative machines on which Assess 
can be run. Meta actuators are invoked 
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Figure 3. Meta function layers. Figure 4. Meta process architecture. 


to restart Assess with the correct spool 
file and reestablish connections to the 
rest of the application. 

AppManager fault tolerance and ato¬ 
micity. AppManager itself must toler¬ 
ate failures. The easiest way to handle 
this is to replicate AppManager using 
the primary backup scheme supported 
by Meta. If all copies of AppManager 
crash, they can regain much of their 
state by interrogating the application 
and environment through sensors. The 
Isis spooler can checkpoint other im¬ 
portant state. Thus the programmer can 
concentrate on writing a consistent set 
of policy rules for AppManager, leav¬ 
ing most of the fault-tolerance issues to 
Meta. 


Instrumenting a 
distributed application 

Using Meta to manage an application 
like NuMon takes three steps. The pro¬ 
grammer instruments the application 
and its environment with sensors and 
actuators. These functions, along with a 
set of built-in sensors and actuators, 
provide the interface between the con¬ 
trol program and the application pro¬ 
gram. 

The programmer then describes the 
application structure using Lomita’s 
object-oriented data modeling facilities. 
(Meta can be viewed as providing an 


object-oriented temporal database in 
which the application and environment 
provide the data values.) 

Finally, the programmer writes a con¬ 
trol program referencing the data mod¬ 
el. The control program may be written 
as a Lomita script or in a conventional 
language embedded with calls to the 
Lomita language translator. The con¬ 
trol program can make direct calls on 
sensors, actuators, and other functions 
in the data model. It can also use higher 
level policy rules that specify a set of 
conditions over sensors and the action 
to take when a given condition is true. 
Figure 3 shows the functional layering 
in the Meta system. 

Figure 4 shows this functional archi¬ 
tecture of the NuMon application. Most 
Meta functions are provided by the Meta 
library (a copy of the library is linked to 
every application process). The library 
contains routines with which an appli¬ 
cation component declares its primitive 
sensors and actuators. Besides applica¬ 
tion processes such as SigPro and As¬ 
sess, the Meta-supplied Machine pro¬ 
cesses provide built-in sensors and 
actuators. 

The other major part of Meta con¬ 
cerns the translation and execution of 
Lomita. The Lomita compiler takes 
source language statements that are read 
from a file or dynamically generated by 
a program such as AppManager and 
translates them into the NPL language. 
Each copy of the Meta library contains 
an NPL interpreter. The object pro¬ 


gram is downloaded to the application 
processes and executed in a distributed 
fashion by these interpreters. 

Sensors. A Meta sensor represents 
part of the state of the monitored appli¬ 
cation. Each sensor is identified by the 
kind of application component it moni¬ 
tors (such as SigPro), the kind of value 
it monitors (say, backlog), and the in¬ 
stance of the component it is monitor¬ 
ing (such as SigProl). 

Built-in sensors. Meta provides a set 
of built-in sensors that correspond to 
information obtained directly from the 
environment. Examples are sensors that 
return statistics such as the memory and 
processor usage of a Unix process. Fur¬ 
thermore, Meta provides the read_var 
sensor for reading the values of certain 
kinds of global variables in an active 
process. This is implemented with the 
Unix system call that permits access to 
another process’s address space for de¬ 
bugging purposes. The built-in alive 
sensor returns the true value as long as 
it monitors an unfailed component. 

User-defined, sensors. Meta allows the 
programmer to define and implement 
primitive sensors. Such sensors corre¬ 
spond to dynamic properties of the ap¬ 
plication whose values cannot be sup¬ 
plied by simply polling the state of the 
underlying operating system. Sensors 
in this class are registered with Meta at 
runtime. Each application process that 
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Machine: external entityset 
attributes 

key name: string 
sensor load: real 
sensor users: {string} 
sensor n_users: integer := size(users) 
sensor jobs: {string} 
actuator exec(string, string) 
end 
end 

FreeMachines : Machine aggregate 
attributes 
key unique 
end 

select m suchthat size(Machine[m].jobs) < = 1 & Machinefmj.load < = 0.5 

end 

Process: dependent Task entityset 
attributes 

key instance: UID := new_uid() 
property params: string 
property executable_file_name: string 
sensor alive: integer 
sensor read_var(string): any 
actuator write_var(string, any) 
actuator exit 
end 
end 

SigPro: Process entityset 
attributes 

sensor load: integer 

sensor high_load: integer := max(history(load, 600)) 
property executable_file_name: string := “/usr/numon/bin/sigpro” 
actuator reset_file (string) 
end 
end 

SigProTask: Task relation SigPro - > Machine 

attributes 

sensor load_ratio: real := SigPro.load / Machine.load 

end 

end 

SigProGroup: SigPro aggregate 
attributes 

key program_name: string 

sensor medianjoad: integer := median(Process.load) 

end 

select all 
end 


Figure 5. Data model for seismological application. 


contains a user-defined sensor must 
connect itself to Meta when it is started 
up by calling the meta_stub_init routine 
in the Meta runtime library: 

meta_stub_init (name, instance); 

The name argument is the compo¬ 


nent type name (say, SigPro) and in¬ 
stance is an instance identifier (say, Sig- 
Prol). The application writer must en¬ 
sure that instance identifiers are unique 
for a given component type. 

Having issued this call, the process 
can explicitly export sensors. For exam¬ 
ple, the following C programming lan¬ 


guage procedure implements a simple 
SigPro load sensor: 

int work_load (int *value) 

{ 

♦value = work_queue_size 
+ 2*mbytes_in_use; 
return (0); 

} 

In this example, work_queue_size and 
mby tes_in_use are global variables main¬ 
tained elsewhere in the process. This 
sensor procedure is made available to 
Meta by calling: 

sensor_id = meta_new_sensor 
(workjoad, “load”, 
TYPEJNTEGER, 10000); 

The meta_new_sensor procedure re¬ 
turns an internal identifier by which the 
process can refer to the sensor instance 
in later communication with Meta. The 
first two arguments establish the bind¬ 
ing between the sensor name and the 
procedure that returns the sensor val¬ 
ue. The third argument specifies the 
type of sensor value, and the fourth 
argument defines the maximum polling 
interval in milliseconds. The sensor 
should be polled at this (or a shorter) 
period to avoid missing significant 
events. 

If the polling interval is specified as 
the constant NE VER_POLL, Meta does 
not periodically poll this sensor. Instead 
the application must call the meta_notify 
routine when the value being sensed 
changes in a significant way. This rou¬ 
tine takes a list of sensor identifiers. For 
example: 

sensor_ids[0] = memory _in_use; 
sensor_ids[l] = load_factor; 
meta_notify (2 /* Size of array */, 
sensor_ids); 

If the value of a sensor is simply the 
contents of a single global variable in a 
process, which is the case with the Sig¬ 
Pro backlog sensor, Meta’s built-in 
read_var sensor can be used. This avoids 
the need to link the Meta library with 
this process, which simplifies adding 
application management to existing pro¬ 
grams. 

Actuators. Meta supplies a number 
of built-in actuators that are named and 
referenced in the same fashion as sen¬ 
sors. These include an actuator to start 
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up a process with a given argument list 
and a write_var actuator that allows 
global variable modification. 

Users can instrument a process by 
defining actuator procedures in a simi¬ 
larway to sensor procedures. For exam¬ 
ple, we could have a SigPro checkpoint 
actuator that checkpoints the process 
state to disk for fault tolerance. The 
SigPro program declares this actuator 
by calling: 

actuator_id = meta_new_actuator 
(checkpoint, “checkpoint”) 

An actuator can take a variable num¬ 
ber of arguments and return a Boolean 
indicating the action’s success or fail¬ 
ure. 

Concurrency issues. To avoid incon¬ 
sistent values or actions, user-defined 
sensors and actuators should be invoked 
only at well-defined points in the execu¬ 
tion of a process. To prevent inconsis¬ 
tencies, Meta and the underlying pro¬ 
cess execute strictly as coroutines. The 
application process must call 
meta_notify (possibly with an empty 
sensor list) at least as often as the small¬ 


est sensor polling interval. With read_var 
and write_var, however, the only syn¬ 
chronization provided is the atomicity 
(if any) of reads and writes to a word of 
memory. Thus the global variable’s val¬ 
ue should be represented in one word or 
less. 

Describing the 
application 

The next step is declaring the applica¬ 
tion’s structure to Meta. 

Lomita data model. The programmer 
develops a schema using the Lomita 
data modeling language to describe an 
application. Components in the appli¬ 
cation and the environment are mod¬ 
eled by entities, following entity-rela¬ 
tionship database terminology. 3 Lomita 
provides ways to specify a rich set of 
connections and groupings between 
components, expressing the structure 
of the application. Figure 5 shows how 
part of the seismological monitoring 
application would be described in Lo¬ 
mita. The accompanying glossary de¬ 


scribes some details of the Lomita data 
modeling facilities. 

Mapping application components to 
process groups. Meta includes the no¬ 
tion of an aggregate: a collection of 
same-type components. In Figure 5 the 
FreeMachines aggregate collects a sub¬ 
set of the Machine components that are 
lightly loaded. Meta arranges for all 
processes in an aggregate to join a cor¬ 
responding Isis process group. A pro¬ 
cess group also exists for each compo¬ 
nent type. 

An Isis group provides an easy way to 
organize components and to communi¬ 
cate with them. Isis multicast simulta¬ 
neously accesses all instances of a sen¬ 
sor or actuator in components of a given 
type. The multicast is atomic: An actu¬ 
ator invocation is received by all group 
members or by none. In addition, con¬ 
current multicasts are ordered consis¬ 
tently at all group members, and Isis 
group semantics ensure that Meta has 
accurate knowledge of the current mem¬ 
bership of an aggregate or type. Chang¬ 
es to the membership of a group, either 
planned (such as when a new compo¬ 
nent joins a group) or unplanned (such 


Lomita data model glossary 


Actuator — A Meta actuator. 

Aggregate — Groups related entities into a single new 
entity, which can define attributes of its own. For example, 
the FreeMachines aggregate collects a subset of lightly 
loaded Machine entities. The members of an aggregate can 
be specified by a select operation and must be drawn from 
the same entity set. An aggregate inherits all attributes of its 
base entity. Thus the FreeMachines aggregate includes an 
exec actuator derived from the Machine.exec actuator. An 
attribute such as FreeMachines.exec behaves like a set¬ 
valued attribute, with one element for each member of the 
aggregate. 

Attribute — A field or instance variable in an entity. Lomita 
supports three kinds of attributes: properties, sensors, and 
actuators. 

Dependent entity set — Specifies that members of one enti¬ 
ty set cannot exist without a corresponding member in some 
other entity set. For instance, the definition for Process speci¬ 
fies that a Process entity is dependent upon the existence of 
some Machine entity through the relationship set Task. 

Entity — Similar to a record or an object in a programming 
language and represents a component in the application or 
environment. The example includes a Machine entity that 


models a computer and a Process entity that is a process run¬ 
ning on a computer. 

Entity set — Contains like entities. This is similar to a data type 
or class in a programming language. 

Primary key — One or more properties belonging to an entity 
set that uniquely identify an entity. For instance, the primary 
key of the machine entity might be its name. 

Property — An attribute whose value is stored in an internal 
database rather than being sensed directly from the application 
or its environment. 

Relationship set — Specifies a one-to-one (<->), many-to- 
one (- > ), or many-to-many (— ) relationship between compo¬ 
nents. For instance, there is a many-to-one relationship be¬ 
tween processes and the machine on which they run. 

Sensor — A Meta sensor. 

Subtype — Declares one entity set to be an extension of an¬ 
other. The subtype inherits all the original entity’s attributes and 
optionally adds new ones. An inherited attribute that had type 
“any” in the parent can be refined to a specific type in the new 
entity set. An example is the SigPro entity set based on the 
Process entity. 


August 1991 


47 




SigProGroup 
aggregate 
and SigPro 
entity set 


as a process failure), are seri¬ 
alized with group communi¬ 
cation. Figure 6 shows the 
group structure. 

Derived sensors. Primitive 
sensor values obtained from 
the application program can 
combine in the form of de¬ 
rived sensors, which provide 
a higher level view of pro¬ 
gram behavior. A derived 
sensor can combine values 
from a number of different 
primitive sensors, or from a 
single sensor over time. De¬ 
rived sensors are defined by 
simple arithmetic expressions 
augmented with more powerful com¬ 
bining operations. 

The following example (taken from 
the definition of SigProTask in Figure 
5) defines a sensor load_ratio comput¬ 
ed from the ratio of SigPro load to the 
Machine load: 

sensor load_ratio: real := 

SigPro.load / Machine.load 

In addition to simple arithmetic opera¬ 
tions, Lomita and NPL provide func¬ 
tions that operate over sets of values, 
including max, min, size, and median. 
There are several sources of set-valued 
data in Lomita to which these functions 
can be applied. First, there are set-val¬ 
ued sensors such as Machine.users. The 
following sensor definition (taken from 
the Machine component in Figure 5) 
computes the current number of users 
on a machine: 

sensor n_users: integer := 
size(users) 

Second, the function history (j, t) 
computes a set containing the values 
that sensor s has taken over the pre¬ 
vious t seconds. The following exam¬ 
ple (from SigPro in Figure 5) defines a 
derived sensor high_load that is the 
maximum load over the last 10 min¬ 
utes: 


Machine enitity set 





Process entity set 
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Figure 6. Lomita process group structure. 


computes the median load of all Sig- 
Pros in the group: 

sensor medianjoad: integer := 
median(Process.load) 

Expressing policy rules 

We now describe the highest level of 
Meta: the rule-based control language. 
The programmer writes a description 
of the intended behavior of the system 
consisting of a set of Lomita policy 
rules of the form: 

when condition do action 

This statement declares that when the 
specified condition is observed, the stat¬ 
ed action should be taken. The condi¬ 
tion part of each rule is a predicate 
expressed on the underlying data mod¬ 
el. The action component is simply a 
sequence of expressions involving ac¬ 
tuators and sensors. 

Figure 7 shows how part of the con¬ 
trol program for the NuMon applica¬ 
tion would look. The when rule states 
that when the number of SigPros be¬ 
comes too low or their collective load 
becomes too high and remains contin¬ 
uously high for at least 60 seconds, a 
new SigPro is to be started. 


gregate sensor. Marzullo 4 
fully discusses this approach 
to tolerating inaccurate sen- 


Actions. The body of the 
when statement specifies a 
linear sequence of actions. 
A chain of rules in which 
each action triggers the con¬ 
dition of the next rule 
achieves a more complex 
control flow. 

In Figure 7, the action part 
starts up a new SigPro pro¬ 
cess on a lightly loaded ma¬ 
chine. The first action cre¬ 
ates a SigPro object in the 
Lomita data model, initializing the 
params field. Note that at this point 
there is no associated Unix process. The 
second action selects a suitable machine 
from the FreeMachines aggregate and 
starts up a process on that machine 
using the appropriate executable file 
and initial job parameters. The 
FreeMachines.exec actuator is really a 
collection of Machine.exec actuators, 
one for each machine in the aggregate. 
Here we wish to select one machine and 
invoke the actuator. The on... orderedby 
syntax achieves this. The clause speci¬ 
fies how many actuators are to be in¬ 
voked (one in this case) and a sensor 
expression to prioritize ordering for the 
selection. In this example, the machine 
with the lightest load is chosen. The 
final step is to create a Task object that 
relates the newly created SigPro with 
the Machine on which it is running. 

This rule is too simplistic for a real 
application. For instance, if a SigPro 
process continually fails upon startup 
because of a software bug, this rule con¬ 
tinually attempts to restart it. In reality, 
such a rule would need a more complex 
condition that could check for repeated 
restarts within a short period, such as 5 
minutes, and other rules would watch 
for repeated failures and notify an op¬ 
erator. 


sensor high_load: integer := 
max(history(load, 600)) 

Finally, the individual sensors of the 
components constituting an aggregate 
can be treated as a set. Thus median(s) 
is the median value of the sensors s of 
each component of the containing ag¬ 
gregate. The following sensor defini¬ 
tion (from SigProGroup in Figure 5) 


Conditions. The form of conditions 
is limited to simple predicates, option¬ 
ally appearing in a temporal logic ex¬ 
pression (the temporal operators are 
explained in the Table 1). 

Derived sensors can present their 
values as ranges or intervals. This can 
be useful to express known tolerances 
of the underlying primitive sensors or 
the value range obtained from an ag- 


Lomita rule interpreter. A Lomita 
control program is compiled into NPL. 
Interpreters residing in the Meta library 
execute the compiled program in a dis¬ 
tributed fashion. NPL’s basic program 
object, like Lomita’s, is a set of condi¬ 
tion-action rules. However, where Lo¬ 
mita supports a rich syntax of expres¬ 
sions over the objects in the data model, 
NPL provides simple postfix expressions 
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over primitive sensors and actuators. 
Furthermore, a given NPL expression is 
tied to a specific process, and it must 
reference nonlocal sensors explicitly. 
The Lomita compiler distributes pieces 
of the compiled control program among 
the interpreters in the application com¬ 
ponents. In so doing, it endeavors to 
minimize references to nonlocal sen¬ 
sors and actuators to improve response 
time. In particular, a rule that referenc¬ 
es sensors and actuators belonging to a 
single component will be executed en¬ 
tirely locally by the interpreter at that 
component. 

Rule interpretation. The execution 
of a Lomita when-do rule can be viewed 
as the execution of a finite-state autom¬ 
aton. Simple conditions that do not deal 
with time map into a single transition 
arc in the automaton. An interval tem¬ 
poral logic expression translates into 
multiple transitions in the automaton. 

We explain the details of Lomita in¬ 
terpretation by describing the execu¬ 
tion of the rule shown in Figure 7. The 
when condition has two parts. The first 
detects when the number of SigPros 
drops below two: 

when size(SigProGroup 
[program_name]) < 2 

To detect when this term is satisfied, 
a list is formed of the tasks belonging to 
the SigProGroup aggregate, and the size 
function is applied to that aggregate. 
The Meta interpreter handling the Sig¬ 
ProGroup aggregate reevaluates the size 
function whenever a process joins or 
leaves the aggregate process group. 

The second part of the when condi¬ 
tion detects when the composite load 
on the SigPrOs exceeds five for 1 minute 
or more: 

during SigProGroup 
[program_name].load > 5 for 60 
always SigProGroup 
[program_name].load > 5 

The whole when expression is con¬ 
verted to the finite-state automaton 
shown in Figure 8. 

In this case, the interpreter that han¬ 
dles the SigProGroup aggregate exe¬ 
cutes the entire rule. 

Fault tolerance of the NPL imple¬ 
mentation. Multiple interpreters are 
assigned the task of handling the sen- 


when size(SigProGroup[program_name]) < 2 or 

(during SigProGroup[program_name].load > 5 for 60 
always SigProGroup[program_name].load > 5) 

do 

P: Process := create SigPro(params := “/usr/numon/data” ) 

M: Machine := FreeMachines.exec(P.executable_file_name, P.params) 
on 1 orderedby FreeMachines.load 
create Task(Machine := M, Process := P) 

end 


Figure 7. Rule for creating new SigPros. 


Table 1. Temporal operators in Lomita. 


Expression 

Meaning 

During I always P 

True if and only if predicate P is true 
throughout time interval / 

During I occurs P 

True if and only if predicate P is true at 
some point within time interval I 

P until Q 

Expresses the time interval beginning when 
predicate P next becomes true, until 
predicate Q subsequently becomes true 

P for T 

Expresses the time interval beginning when 
predicate P next becomes true, until T 
seconds have passed 


sors and actuators associated with each 
component type or aggregate. One of 
the interpreters is chosen to have pri¬ 
mary responsibility, while the extra pro¬ 
cesses are backups. 

Despite this redundancy, all NPL in¬ 
terpreters can fail at once. To cope with 
this, each application process can mon¬ 
itor for the total failure of the interpret¬ 
er group. If this happens, the applica¬ 
tion normally terminates itself. Simply 
restarting Lomita from its initialization 
files starts up the application in an or¬ 
derly way. Because the application ter¬ 
minates itself, no “orphan” application 
processes can survive the failure of the 
control program. Such processes would 
generate much confusion when the ap¬ 
plication was restarted. 

A second option is to leave surviving 
application processes running and have 
the control program search on startup 
for existing processes. In our example, 
it would look for any members in the 
SigPro process group. Once the orphans 
were identified, they could be terminat¬ 
ed or reinitialized and integrated into 
the new version. We have not provided 
support for orphan detection in the 
Lomita language; however, an Isis pro¬ 
gram could perform this function at 


application startup. A third option we 
have not explored is having the inter¬ 
preters checkpoint their state to disk. 

Atomicity of actions. For simple ac¬ 
tions consisting of one actuator call (to 
one process or to the set of processes in 
an aggregate), Isis atomic broadcast 
provides necessary concurrency control. 

However, when Meta operations trig¬ 
ger multiple actuators, concurrency and 
failure atomicity are more difficult. For 
example, suppose a Meta rule reacts to 
a failure by selecting a lightly loaded 
machine, reserving it, and instantiating 
a program on it. If several such rules are 
triggered simultaneously, a machine 
must not be reserved more than once. A 
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similar case can arise when one member 
of an aggregate takes over after another 
member has failed. We are currently 
implementing a form of atomic transac¬ 
tions to permit atomic invocation of 
multiple actuators. 

Performance and real¬ 
time behavior 

With Meta, a distributed application- 
management control program is a soft, 
real-time reactive system. Producing a 
robust control program mandates han¬ 
dling such issues as the accuracy inter¬ 
vals for sensors and the latency before 
actuators take effect. 

Performance. Meta must provide a 
predictable, short delay between the 
occurrence of a condition and its notifi¬ 
cation to the control program. We mea¬ 
sured the cost of executing the rule: 

when S do A, 

where S is a trivial sensor and A is a 
trivial actuator. The times were mea¬ 
sured on two Sun Microsystems 4/60s 
with a 10-megabit-per-second Ethernet, 
and Isis Version 3.0. Variance was less 
than 2 percent. The local cost of execut¬ 
ing a rule was 84 microseconds. To this 
must be added the cost of checking for 
external events (involving the Unix se¬ 
lect call), which can be substantial. When 
S and A actually resided on a machine 
that did not execute the rule, the cost 
was 17.1 milliseconds. It is clear that 
performance of the control program 
depends strongly on the locality of NPL 
expressions. References to local sen¬ 
sors and actuators, that is, ones that 
exist in the current process, are very 
fast. Accessing sensors and actuators 
on processes on other machines is rela¬ 
tively more expensive but quite ade¬ 
quate for the applications we have seen 
so far. 

Real-time behavior on Unix and Isis. 

The predictability of Meta performance 
is at least as important as its absolute 
speed. These performance figures ex¬ 
hibited little variance because they were 
executed under controlled conditions. 
The current Isis implementation and 
the Unix operating system on which 
Meta executes do not provide predict¬ 
able performance. One can conserva¬ 
tively assume that the end-to-end sen¬ 


sor latency can be as long as several 
seconds. It remains for the application 
programmer to specify the accuracy in¬ 
tervals for sensors and the maximum 
meaningful polling period. For manag¬ 
ing most kinds of applications, polling 
intervals of several seconds or minutes 
are reasonable. 


Other technologies 

Although distributed application 
management is relatively new, Meta 
employs techniques drawn from exist¬ 
ing work in distributed computing in¬ 
cluding performance monitoring, debug¬ 
ging, and operating systems. 

The idea of viewing the data gathered 
from monitoring as a temporal data¬ 
base is due principally to Snodgrass. 5 A 
related project, the Issos system, 6 is sim¬ 
ilar to Meta in that it combines monitor¬ 
ing with control. Meta’s use of rule- 
based techniques resembles expert 
systems used in soft real-time control 
applications. 7 Rule-based techniques are 
also used in debuggers for concurrent 
programs, such as Bruegge’s Pathrules 
language, 8 that provide a kind of pro¬ 
duction rule breakpoint. This consists 
of a condition over variables and pro¬ 
gram counters of several processes. This 
condition triggers an action such as sus¬ 
pending the program. 

Many functions of what we call the 
control program are more usually asso¬ 
ciated with an operating system: in 
particular, scheduling and resource man¬ 
agement. In a general-purpose distrib¬ 
uted operating system such as Locus, 9 
the set of resources and control param¬ 
eters is fixed by the operating system 
and is usually limited to the lowest com¬ 
mon denominator of the applications 
envisaged. A common facility is remote 
execution, in which unrelated nondis- 
tributed programs are allocated to or 
migrated between machines to share 
the available load more evenly. 10 Load 
sharing is easily implemented using 
Meta, but the system provides much 
richer facilities for describing the inter¬ 
relationships and dependencies between 
the processes that make up a true dis¬ 
tributed application. 

A few systems for controlling or con¬ 
figuring distributed applications take a 
more structured view of the applica¬ 
tion, permitting a finer degree of con¬ 
trol. The RM2 distributed resource 
manager" permits the construction of 
compound software resources, which are 


similar to our notion of a distributed 
application. In the Conic language and 
system, 12 an application is structured 
as a set of modules and communication 
ports. Conic supports dynamic recon¬ 
figuration by allowing new modules to 
be created and existing ports to be 
reconnected at runtime through a 
graphical user interface. RM2 and Conic 
lack a general notion corresponding to 
either sensors or actuators. This makes 
it difficult for configuration scripts to 
react to changes in the application or 
its environment, and reconfiguration 
is restricted to modifying module con¬ 
nections and creating new modules. 

Other Meta project 
work 

The real-time requirements of dis¬ 
tributed application management are 
minimal, certainly for the applications 
we have considered to date. However, 
the Meta model can be extended to 
handle real-time environments and con¬ 
tinuously valued sensors. 4 The main 
obstacle is real-time multicast and a 
real-time operating system platform. 
Robbert van Renesse of the Free Uni¬ 
versity, Amsterdam, has developed a 
graphical user interface for distributed 
control called Magic Lantern that works 
with Meta. A graphical editor comple¬ 
ments a textual control language by 
letting users experiment with control 
strategies before writing a control pro¬ 
gram. 


D istributed computing holds the 
promise of improved flexibil¬ 
ity, reliability, and perfor¬ 
mance. But many system developers 
find that promise unfulfilled because 
the necessary tools are lacking. We 
believe that distributed application 
management is one of the more impor¬ 
tant — but neglected — areas in the 
field. The Meta system fills this gap by 
making it easier to build robust distrib¬ 
uted applications using components that 
cannot individually tolerate faults. De¬ 
signers can more easily plan and estab¬ 
lish the correctness of the resulting 
control structures. These are impor¬ 
tant steps towards the open, heteroge¬ 
neous distributed operating systems 
that will characterize the next genera¬ 
tion of distributed environments. 

Version 2.0 of Meta using the Isis 
system is being distributed in source 
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code from within the Isis user com¬ 
munity of several hundred sites. This 
version contains a complete imple¬ 
mentation of the Meta sensor and ac¬ 
tuator subroutine interface we de¬ 
scribed, the built-in Machine and 
Process sensors, and the NPL inter¬ 
preter. The Lomita language is still 
being implemented. ■ 
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Distributed Shared 
Memory: A Survey 
of Issues and Algorithms 


Bill Nitzberg and Virginia Lo, University of Oregon 


Distributed shared- 
memory systems 
implement the shared- 
memory abstraction on 
multicomputer 
architectures, 
combining the 
scalability of network- 
based architectures 
with the convenience of 
shared-memory 
programming. 


A s we slowly approach the physical limits of processor and memory speed, 
it is becoming more attractive to use multiprocessors to increase comput¬ 
ing power. Two kinds of parallel processors have become popular: tightly 
coupled shared-memory multiprocessors and distributed-memory multiproces¬ 
sors. A tightly coupled multiprocessor system — consisting of multiple CPUs and 
a single global physical memory — is more straightforward to program because it 
is a natural extension of a single-CPU system. However, this type of multiprocessor 
has a serious bottleneck: Main memory is accessed via a common bus — a 
serialization point — that limits system size to tens of processors. 

Distributed-memory multiprocessors, however, do not suffer from this draw¬ 
back. These systems consist of a collection of independent computers connected by 
a high-speed interconnection network. If designers choose the network topology 
carefully, the system can contain many orders of magnitude more processors than 
a tightly coupled system. Because all communication between concurrently exe¬ 
cuting processes must be performed over the network in such a system, until 
recently the programming model was limited to a message-passing paradigm. 
However, recent systems have implemented a shared-memory abstraction on top 
of message-passing distributed-memory systems. The shared-memory abstraction 
gives these systems the illusion of physically shared memory and allows program¬ 
mers to use the shared-memory paradigm. 

As Figure 1 shows, distributed shared memory provides a virtual address space 
shared among processes on loosely coupled processors. The advantages offered by 
DSM include ease of programming and portability achieved through the shared- 
memory programming paradigm, the low cost of distributed-memory machines, 
and scalability resulting from the absence of hardware bottlenecks. 

DSM has been an active area of research since the early 1980s, although its 
foundations in cache coherence and memory management have been extensively 
studied for many years. DSM research goals and issues are similar to those of 
research in multiprocessor caches or networked file systems, memories for nonuni¬ 
form memory access multiprocessors, and management systems for distributed or 
replicated databases. 1 Because of this similarity, many algorithms and lessons 
learned in these domains can be transferred to DSM systems and vice versa. 
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Figure 1. Distributed shared memory. 


However, each of the above systems has 
unique features (such as communica¬ 
tion latency), so each must be consid¬ 
ered separately. 

The advantages of DSM can be real¬ 
ized with reasonably low runtime over¬ 
head. DSM systems have been imple¬ 
mented using three approaches (some 
systems use more than one approach): 

(1) hardware implementations that 
extend traditional caching tech¬ 
niques to scalable architectures, 

(2) operating system and library 
implementations that achieve 
sharing and coherence through 
virtual memory-management 
mechanisms, and 

(3) compiler implementations where 
shared accesses are automatically 
converted into synchronization 
and coherence primitives. 

These systems have been designed on 
common networks of workstations or 
minicomputers, special-purpose mes¬ 
sage-passing machines (such as the 
Intel iPSC/2), custom hardware, and 
even heterogeneous systems. 

This article gives an integrated over¬ 
view of important DSM issues: memory 
coherence, design choices, and imple¬ 
mentation methods. In our presenta¬ 
tion, we use examples from the DSM 
systems listed and briefly described in 
the sidebar on page 55. Table 1 com¬ 
pares how design issues are handled in a 
selected subset of the systems. 

Design choices 

A DSM system designer must make 
choices regarding structure, granulari¬ 
ty, access, coherence semantics, seal- 
ability, and heterogeneity. Examination 
of how designers handled these issues in 
several real implementations of DSM 
shows the intricacies of such a system. 

Structure and granularity. The struc¬ 
ture and granularity of a DSM system 
are closely related. Structure refers to 
the layout of the shared data in mem¬ 
ory. Most DSM systems do not struc¬ 
ture memory (it is a linear array of 
words), but some structure the data as 
objects, language types, or even an as¬ 
sociative memory. Granularity refers to 
the size of the unit of sharing: byte, 
word, page, or complex data structure. 

Ivy, 2 one of the first transparent DSM 


systems, implemented shared memory 
as virtual memory. This memory was 
unstructured and was shared in 1-Kbyte 
pages. In systems implemented using 
the virtual memory hardware of the 
underlying architecture, it is convenient 
to choose a multiple of the hardware 
page size as the unit of sharing. Mirage 3 
extended Ivy’s single shared-memory 
space to support a paged segmentation 
scheme. Users share arbitrary-size re¬ 
gions of memory (segments) while the 
system maintains the shared space in 
pages. 

Hardware implementations of DSM 
typically support smaller grain sizes. For 
example. Dash 4 and Memnet 5 also sup¬ 
port unstructured sharing, but the unit 
of sharing is 16 and 32 bytes respec¬ 
tively — typical cache line sizes. Plus 6 is 
somewhat of a hybrid: The unit of rep¬ 
lication is a page, while the unit of co¬ 
herence is a 32-bit word. 

Because shared-memory programs 
provide locality of reference, a process 
is likely to access a large region of its 
shared address space in a small amount 
of time. Therefore, larger “page” sizes 
reduce paging overhead. However, shar¬ 
ing may also cause contention, and the 
larger the page size, the greater the 
likelihood that more than one process 
will require access to a page. A smaller 
page reduces the possibility of false shar¬ 
ing, which occurs when two unrelated 
variables (each used by different pro¬ 
cesses) are placed in the same page. The 
page appears shared, even though the 


original variables were not. Another 
factor affecting the choice of page size is 
the need to keep directory information 
about the pages in the system: the small¬ 
er the page size, the larger the directory. 

A method of structuring the shared 
memory is by data type. With this 
method, shared memory is structured 
as objects in distributed object- 
oriented systems, as in the Emerald, 
Choices, and Clouds 7 systems; or it is 
structured as variables in the source 
language, as in the Shared Data-Object 
Model and Munin systems. Because with 
these systems the sizes of objects and 
data types vary greatly, the grain size 
varies to match the application. How¬ 
ever, these systems can still suffer from 
false sharing when different parts of an 
object (for example, the top and bottom 
halves of an array) are accessed by dis¬ 
tinct processes. 

Another method is to structure the 
shared memory like a database. Linda, 8 
a system that has such a model, orders 
its shared memory as an associative 
memory called a tuple space. This struc¬ 
ture allows the location of data to be 
separated from its value, but it also re¬ 
quires programmers to use special ac¬ 
cess functions to interact with the shared- 
memory space. In most other systems, 
access to shared data is transparent. 

Coherence semantics. For program¬ 
mers to write correct programs on a 
shared-memory machine, they must 
understand how parallel memory up¬ 
dates are propagated throughout the 
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Table 1. DSM design issues. 


System 

Name 

Current 

Implementation 

Structure 

and 

Granularity 

Coherence 

Semantics 

Coherence 

Protocol 

Sources of 
Improved 
Performance 

Support 
for Synchro¬ 
nization 

Hetero¬ 

geneous 

Support 

Dash 

Hardware, 
modified Silicon 
Graphics Iris 
4D/340 worksta¬ 
tions, mesh 

16 bytes 

Release 

Write- 

invalidate 

Relaxed 

coherence, 

prefetching 

Queued locks, 
atomic incre¬ 
mentation and 
decrementation 

No 

Ivy 

Software, Apollo 
workstations, 
Apollo ring, 
modified Aegis 

1-Kbyte 
pages 

Strict 

Write- 

invalidate 

Pointer chain 
collapse, selec¬ 
tive broadcast 

Synchronized 
pages, sema¬ 
phores, event 
counts 

No 

Linda 

Software, 
variety of 
environments 

Tuples 

No 

mutable 

data 

Varied 

Hashing 


? 

Memnet 

Hardware, 
token ring 

32 bytes 

Strict 

Write- 

invalidate 

Vectored in¬ 
terrupt support 
of control flow 


No 

Mermaid Software, Sun 
workstations 

DEC Firefly 
multiprocessors, 
Mermaid/native 
operating system 

8 Kbytes 
(Sun), 

1 Kbyte 
(Firefly) 

Strict 

Write- 

invalidate 


Messages for 
semaphores 
and signal/ 
wait 

Yes 

Mirage 

Software, VAX 512-byte 
11/750, Ether- pages 

net, Locus dis¬ 
tributed operat¬ 
ing system, Unix 

System V interface 

Strict 

Write- 

invalidate 

Kernel-level 
implementa¬ 
tion, time 
window 
coherence 
protocol 

Unix System V 
semaphores 

No 

Munin 

Software, Sun 
workstations, 
Ethernet, Unix 
System V kernel 
and Presto paral¬ 
lel programming 
environment 

Objects 

Weak 

Type-specific 
(delayed write 
update for 
read-mostly 
protocol) 

Delayed 

update 

queue 

Synchronized 

objects 

No 

Plus 

Hardware and 
software, 

Motorola 88000, 
Caltech mesh, 

Plus kernel 

Page for 
sharing, 
word for 
coherence 

Processor 

Nondemand 

write-update 

Delayed 

operations 

Complex 

synchronization 

instructions 

No 

Shiva 

Software, 

Intel iPSC/2, 
hypercube, 
Shiva/native 
operating system 

4-Kbyte 

pages 

Strict 

Write- 

invalidate 

Data structure 
compaction, 
memory as 
backing store 

Messages for 
semaphores 
and signal/ 

No 


system. The most intuitive semantics 
for memory coherence is strict consis¬ 
tency. (Although “coherence” and “con¬ 
sistency” are used somewhat inter¬ 
changeably in the literature, we use 
coherence as the general term for the 


semantics of memory operations, and 
consistency to refer to a specific kind of 
memory coherence.) In a system with 
strict consistency, a read operation re¬ 
turns the most recently written value. 
However, “most recently” is an ambig¬ 


uous concept in a distributed system. 
For this reason, and to improve perfor¬ 
mance, some DSM systems provide only 
a reduced form of memory coherence. 
For example, Plus provides processor 
consistency, and Dash provides only 
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release consistency. In accordance with 
the RISC philosophy, both of these sys¬ 
tems have mechanisms for forcing co¬ 
herence, but their use must be explicitly 
specified by higher level software (a 
compiler) or perhaps even the program¬ 
mer. 

Relaxed coherence semantics allows 
more efficient shared access because it 
requires less synchronization and less 
data movement. However, programs that 
depend on a stronger form of coherence 
may not perform correctly if executed 
in a system that supports only a weaker 
form. Figure 2 gives brief definitions of 
strict, sequential, processor, weak, and 
release consistency, and illustrates the 
hierarchical relationship among these 
types of coherence. Table 1 indicates 
the coherence semantics supported by 
some current DSM systems. 


Figure 2. Intuitive definitions of mem¬ 
ory coherence. The arrows point from 
stricter to weaker consistencies. 



DSM systems 

This partial listing gives the name of the DSM system, the princi¬ 
pal developers of the system, the site and duration of their research, 
and a brief description of the system. Table 1 gives more informa¬ 
tion about the systems followed with an asterisk. 

Agora (Bisiani and Forin, Carnegie Mellon University, 

1987- ): A heterogeneous DSM system that allows data structures 
to be shared across machines. Agora was the first system to sup¬ 
port weak consistency. 

Amber (Chase, Feeley, and Levy, University of Washington, 

1988- ): An object-based DSM system in which sharing is performed 
by migrating processes to data as well as data to processes. 

Capnet(Tamand Farber, University of Delaware, 1990-): Anex- 
tension of DSM to a wide area network. 

Choices (Johnston and Campbell, University of Illinois, 

1988-): DSM incorporated into a hierarchical object-oriented distrib¬ 
uted operating system. 

Clouds (Ramachandran and Khalidi, Georgia Institute of Tech¬ 
nology, 1987-): An object-oriented distributed operating system 
where objects can migrate. 

Dash* (Lenoski, Laudon, Gharachorloo, Gupta, and Hennessy, 
Stanford University, 1988-): A hardware implementation of DSM 
with a directory-based coherence protocol. Dash provides release 
consistency. 

Emerald (Jul, Levy, Hutchinson, and Black, University of Wash¬ 
ington, 1986-1988): An object-oriented language and system that 
indirectly supports DSM through object mobility. 

Ivy* (Li, Yale University, 1984-1986): An early page-oriented 
DSM on a network of Apollo workstations. 


Linda* (Carriero and Gelernter, Yale University, 1982-): A 
shared associative object memory with access functions. Linda can 
be implemented for many languages and machines. 

Memnet* (Delp and Farber, University of Delaware, 1986-1988): 
A hardware implementation of DSM implemented on a 200-Mbps 
token ring used to broadcast invalidates and read requests. 

Mermaid* (Stumm, Zhou, Li, and Wortman, University of Toronto 
and Princeton University, 1988-1991): A heterogeneous DSM sys¬ 
tem where the compiler forces shared pages to contain a single 
data type. Type conversion is performed on reference. 

Mether (Minnich and Farber, Supercomputing Research Center, 
Bowie, Md., 1990-): A transparent DSM built on SunOS 4.0. 

Mether allows applications to access an inconsistent state for 
efficiency. 

Mirage* (Fleisch and Popek, University of California at Los 
Angeles, 1987-1989): A kernel-level implementation of DSM. 
Mirage reduces thrashing by prohibiting a page from being sto¬ 
len before a minimum amount of time (A) has elapsed. 

Munin* (Bennett, Carter, and Zwaenepoel, Rice University, 

1989-): An object-based DSM system that investigates type- 
specific coherence protocols. 

Plus* (Bisiani and Ravishankar, Carnegie Mellon University, 
1988-): A hardware implementation of DSM. Plus uses a write- 
update coherence protocol and performs replication only by pro¬ 
gram request. 

Shared Data-Object Model (Bal, Kaashoek, and Tannen- 
baum, Vrije University, Amsterdam, The Netherlands, 1988-): A 
DSM implementation on top of the Amoeba distributed operat¬ 
ing system. 

Shiva* (Li and Schaefer, Princeton University, 1988-): An 
Ivy-like DSM system for the Intel iPSC/2 hypercube. 
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Scalability. A theoretical benefit of 
DSM systems is that they scale better 
than tightly coupled shared-memory 
multiprocessors. The limits of seal- 
ability are greatly reduced by two fac¬ 
tors: central bottlenecks (such as the 
bus of a tightly coupled shared- 
memory multiprocessor), and global 
common knowledge operations and 
storage (such as broadcast messages or 
full directories, whose sizes are pro¬ 
portional to the number of nodes). 

Li and Hudak 2 went through several 
iterations to refine a coherence proto¬ 
col for Ivy before arriving at their dy¬ 
namic distributed-manager algorithm, 
which avoids centralized bottlenecks. 
However, Ivy and most other DSM 
systems are currently implemented on 
top of Ethernet (itself a centralized 
bottleneck), which can support only 
about 100 nodes at a time. This limita¬ 
tion is most likely a result of these 
systems being research tools rather than 
an indication of any real design flaw. 
Shiva 9 is an implementation of DSM 
on an Intel iPSC/2 hypercube, and it 
should scale nicely. Nodes in the Dash 
system are connected on two meshes. 
This implies that the machine should 
be expandable, but the Dash proto¬ 
type is currently limited by its use of a 
full bit vector (one bit per node) to 
keep track of page replication. 

Heterogeneity. At first glance, shar¬ 
ing memory between two machines with 
different architectures seems almost 
impossible. The machines may not even 
use the same representation for basic 
data types (integers, floating-point 
numbers, and so on). It is a bit easier if 
the DSM system is structured as vari¬ 
ables or objects in the source language. 
Then a DSM compiler can add conver¬ 
sion routines to all accesses to shared 
memory. In Agora, memory is struc¬ 
tured as objects shared among hetero¬ 
geneous machines. 

Mermaid 10 explores another novel 
approach: Memory is shared in pages, 
and a page can contain only one type of 
data. Whenever a page is moved be¬ 
tween two architecturally different sys¬ 
tems, a conversion routine converts 
the data in the page to the appropriate 
format. 

Although heterogeneous DSM might 
allow more machines to participate in 
a computation, the overhead of con¬ 
version seems to outweigh the bene¬ 
fits. 


Implementation 

A DSM system must automatically 
transform shared-memory access into 
interprocess communication. This re¬ 
quires algorithms to locate and access 
shared data, maintain coherence, and 
replace data. A DSM system may also 
have additional schemes to improve per¬ 
formance. Such algorithms directly sup¬ 
port DSM. In addition, DSM implement- 
ers must tailor operating system 
algorithms to support process synchro¬ 
nization and memory management. We 
focus on the algorithms used in Ivy, Dash, 
Munin, Plus, Mirage, and Memnet be¬ 
cause these systems illustrate most of 
the important implementation issues. 
Stumm and Zhou 1 give a good evolu¬ 
tionary overview of algorithms that sup¬ 
port static, migratory, and replicated 
data. 

Data location and access. To share 
data in a DSM system, a program must 
be able to find and retrieve the data it 
needs. If data does not move around in 
the system — it resides only in a single 
static location — then locating it is easy. 
All processes simply “know” where to 
obtain any piece of data. Some Linda 
implementations use hashing on the tu¬ 
ples to distribute data statically. This 
has the advantages of being simple and 
fast, but may cause a bottleneck if data is 
not distributed properly (for example, 
all shared data ends up on a single node). 

An alternative is to allow data to mi¬ 
grate freely throughout the system. This 
allows data to be redistributed dynami¬ 
cally to where it is being used. However, 
locating data then becomes more diffi¬ 
cult. In this case, the simplest way to 
locate data is to have a centralized 
server that keeps track of all shared 
data. The centralized method suffers 
from two drawbacks: The server serial¬ 
izes location queries, reducing parallel¬ 
ism, and the server may become heavily 
loaded and slow the entire system. 

Instead of using a centralized server, a 
system can broadcast requests for data. 
Unfortunately, broadcasting does not 
scale well. All nodes — not just the 
nodes containing the data — must pro¬ 
cess a broadcast request. The network 
latency of a broadcast may also require 
accesses to take a long time to complete. 

To avoid broadcasts and distribute 
the load more evenly, several systems 
use an owner-based distributed scheme. 


This scheme is independent of data rep¬ 
lication, but is seen mostly in systems 
that support both data migration and 
replication. Each piece of data has an 
associated owner — a node with the 
primary copy of the data. The owners 
change as the data migrates through the 
system. When another node needs a copy 
of the data, it sends a request to the 
owner. If the owner still has the data, it 
returns the data. If the owner has given 
the data to some other node, it forwards 
the request to the new owner. 

The drawback with this scheme is that 
a request may be forwarded many times 
before reaching the current owner. In 
some cases, this is more wasteful than 
broadcasting. In Ivy, all nodes involved 
in forwarding a request (including the 
requester) are given the identity of the 
current owner. This collapsing of 
pointer chains helps reduce the forward¬ 
ing overhead and delay. 

When it replicates data, a DSM sys¬ 
tem must keep track of the replicated 
copies. Dash uses a distributed directo¬ 
ry-based scheme, implemented in hard¬ 
ware. The Dash directory for a given 
cluster (node) keeps track of the physi¬ 
cal blocks in that cluster. Each block is 
represented by a directory entry that 
specifies whether the block is unshared 
remote (local copy only ), shared remote, 
or shared dirty. If the block is shared 
remote, the directory entry also indi¬ 
cates the location of replicated copies of 
the block. If the block is shared dirty, the 
directory entry indicates the location of 
the single dirty copy. Only the special 
node known as the home cluster posses¬ 
ses the directory block entry. A node 
accesses nonlocal data for reading by 
sending a message to the home cluster. 

Ivy’s dynamic distributed scheme also 
supports replicated data. A ptable on 
each node contains for each page an 
entry that indicates the probable loca¬ 
tion for the referenced page. As de¬ 
scribed above, a node locates data by 
following the chain of probable owners. 
The copy-list scheme implemented by 
Plus uses a distributed linked list to keep 
track of replicated data. Memory refer¬ 
ences are mapped to the physically clos¬ 
est copy by the page map table. 

Coherence protocol. All DSM systems 
provide some form of memory coher¬ 
ence. If the shared data is not replicated, 
then enforcing memory coherence is triv¬ 
ial. The underlying network automati¬ 
cally serializes requests in the order they 
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<write request (read-exclusive)> 



(requesting cluster) 


cwrite request (read-exclusive)> 



(home cluster) 

(b) 


Figure 3. Simplified Dash write-invalidate protocol: (a) Data is shared remote; (b) data is dirty remote (after events de¬ 
picted in Figure 3a). (DC stands for directory controller.) 


occur. A node handling shared data can 
merely perform each request as it is 
received. This method will ensure strict 
memory consistency — the strongest 
form of coherence. Unfortunately, seri¬ 
alizing data access creates a bottleneck 
and makes impossible a major advan¬ 
tage of DSM: parallelism. 

To increase parallelism, virtually all 
DSM systems replicate data. Thus, for 
example, multiple reads can be per¬ 
formed in parallel. However, replica¬ 
tion complicates the coherence proto¬ 
col. Two types of protocols — 
write-invalidate and write-update pro¬ 
tocols — handle replication. In a write- 
invalidate protocol, there can be many 


copies of a read-only piece of data, but 
only one copy of a writable piece of 
data. The protocol is called write- 
invalidate because it invalidates all cop¬ 
ies of a piece of data except one before 
a write can proceed. In a write-update 
scheme, however, a write updates all 
copies of a piece of data. 

Most DSM systems have write- 
invalidate coherence protocols. All the 
protocols for these systems are similar. 
Each piece of data has a status tag that 
indicates whether the data is valid, 
whether it is shared, and whether it is 
read-only or writable. For a read, if the 
data is valid, it is returned immediately. 
If the data is not valid, a read request is 


sent to the location of a valid copy, and 
a copy of the data is returned. If the data 
was writable on another node, this read 
request will cause it to become read¬ 
only. The copy remains valid until an 
invalidate request is received. 

For a write, if the data is valid and 
writable, the request is satisfied imme¬ 
diately. If the data is not writable, the 
directory controller sends out an invali¬ 
date request, along with a request for a 
copy of the data if the local copy is not 
valid. When the invalidate completes, 
the data is valid locally and writable, 
and the original write request may com¬ 
plete. 

Figure 3 illustrates the Dash directory- 
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Figure 4. The Plus write-update 
protocol. (MCM stands for 
memory coherence manager.) 
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based coherence protocol. The sequence 
of events and messages shown in Figure 
3a occurs when the block to be written 
is in shared-remote state (multiple read¬ 
only copies on nodes A and B) just 
before the write. Figure 3b shows the 
events and messages that occur when 
the block to be written is in shared-dirty 
state (single dirty copy on node C) just 
before the write. In both cases, the ini¬ 
tiator of the write sends a request to the 
home cluster, which uses the informa¬ 
tion in the directory to locate and trans¬ 
fer the data and to invalidate copies. 
Lenoski et al. 4 give further details about 
the Dash coherence protocol and the 
methods they used to fine-tune the pro¬ 
tocol for high performance. 

Li and Hudak 2 show that the write- 
invalidate protocol performs well for a 
variety of applications. In fact, they show 
superlinear speedups for a linear equa¬ 
tion solver and a three-dimensional par¬ 
tial differential equation solver, result¬ 
ing from the increased overall physical 
memory and cache sizes. Li and Hudak 
rejected use of a write-update protocol 
at the onset with the reasoning that 
network latency would make it ineffi- 

Subsequent research indicates that in 
the appropriate hardware environment 
write-update protocols can be imple¬ 


mented efficiently. For example, Plus is 
a hardware implementation of DSM that 
uses a write-update protocol. Figure 4 
traces the Plus write-update protocol, 
which begins all updates with the block’s 
master node, then proceeds down the 
copy-list chain. The write operation is 
completed when the last node in the 
chain sends an acknowledgment mes¬ 
sage to the originator of the write re¬ 
quest. 

Munin 11 uses type-specific memory 
coherence, coherence protocols tailored 
for different types of data. For example, 
Munin uses a write-update protocol to 
keep coherent data that is read much 
more frequently than it is written (read- 
mostly data). Because an invalidation 
message is about the same size as an 
update message, an update costs no more 
than an invalidate. However, the over¬ 
head of making multiple read-only 
copies of the data item after each inval¬ 
idate is avoided. An eager paging strat¬ 
egy supports the Munin producer- 
consumer memory type. Data, once 
written by the producer process, is trans¬ 
ferred to the consumer proce where 
it remains available until the consumer 
process is ready to use it. This reduces 
overhead, since the consumer does not 
request data already available in the 
buffer. 


Replacement strategy. In systems that 
allow data to migrate around the sys¬ 
tem, two problems arise when the avail¬ 
able space for “caching” shared data 
fills up: Which data should be replaced 
to free space and where should it go? In 
choosing the data item to be replaced, a 
DSM system works almost like the cach¬ 
ing system of a shared-memory multi¬ 
processor. However, unlike most cach¬ 
ing systems, which use a simple least 
recently used or random replacement 
strategy, most DSM systems differenti¬ 
ate the status of data items and priori¬ 
tize them. For example, priority is given 
to shared items over exclusively owned 
items because the latter have to be trans¬ 
ferred over the network. Simply delet¬ 
ing a read-only shared copy of a data 
item is possible because no data is lost. 
Shiva prioritizes pages on the basis of a 
linear combination of type (read-only, 
owned read-only, and writable) and least 
recently used statistics. 

Once a piece of data is to be replaced, 
the system must make sure it is not lost. 
In the caching system of a multiproces¬ 
sor, the item would simply be placed in 
main memory. Some DSM systems, such 
as Memnet, use an equivalent scheme. 
The system transfers the data item to a 
“home node” that has a statically allo¬ 
cated space (perhaps on disk) to store a 
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copy of an item when it is not needed 
elsewhere in the system. This method is 
simple to implement, but it wastes a lot 
of memory. An improvement is to have 
the node that wants to delete the item 
simply page it out onto disk. Although 
this does not waste any memory space, 
it is time consuming. Because it may be 
faster to transfer something over the 
network than to transfer it to disk, a 
better solution (used in Shiva) is to keep 
track of free memory in the system and 
to simply page the item out to a node 
with space available to it. 

Thrashing. DSM systems are par¬ 
ticularly prone to thrashing. For exam¬ 
ple, if two nodes compete for write 
access to a single data item, it may be 
transferred back and forth at such a 
high rate that no real work can get done 
(a Ping-Pong effect). Two systems, 
Munin and Mirage, attack this problem 
directly. 

Munin allows programmers to associ¬ 
ate types with shared data: write-once, 
write-many, producer-consumer, pri¬ 
vate, migratory, result, read-mostly, syn¬ 
chronization, and general read/write. 
Shared data of different types get dif¬ 
ferent coherence protocols. To avoid 
thrashing with two competing writers, a 
programmer could specify the type as 
write-many and the system would use a 
delayed write policy. (Munin does not 
guarantee strict consistency of memory 
in this case.) 

Tailoring the coherence algorithm to 
the shared-data usage patterns can 
greatly reduce thrashing. However, 
Munin requires programmers to specify 
the type of shared data. Programmers 
are notoriously bad at predicting the 
behavior of their programs, so this 
method may not be any better than 
choosing a particular protocol. In addi¬ 
tion, because the type remains static 
once specified, Munin cannot dynami¬ 
cally adjust to an application’s changing 
behavior. 

Mirage 3 uses another method to re¬ 
duce thrashing. It specifically examines 
the case when many nodes compete for 
access to the same page. To stop the 
Ping-Pong effect, Mirage adds a dynam¬ 
ically tunable parameter to the coher¬ 
ence protocol. This parameter deter¬ 
mines the minimum amount of time (A) 
a page will be available at a node. For 
example, if a node performed a write to 
a shared page, the page would be writ¬ 
able on that node for A time. This solves 


the problem of having a page stolen 
away after only a single request on a 
node can be satisfied. Because A is tuned 
dynamically on the basis of access pat¬ 
terns, a process can complete a write 
run (or read run) before losing access to 
the page. Thus, A is akin to a time slice 
in a multitasking operating system, ex¬ 
cept in Mirage it is dynamically ad¬ 
justed to meet an application’s specific 
needs. 

Related algorithms. To support a DSM 
system, synchronization operations and 
memory management must be specially 
tuned. Semaphores, for example, are 
typically implemented on shared- 
memory systems by using spin locks. In 
a DSM system, a spin lock can easily 
cause thrashing, because multiple nodes 
may heavily access shared data. For 
better performance, some systems pro¬ 
vide specialized synchronization primi¬ 
tives along with DSM. Clouds provides 
semaphore operations by grouping 
semaphores into centrally managed seg¬ 
ments. Munin supports the synchroni¬ 
zation memory type with distributed 
locks. Plus supplies a variety of syn¬ 
chronization instructions, and supports 
delayed execution, in which the syn¬ 
chronization can be initiated, then later 
testedfor successful completion. Dubois, 
Scheurich, and Briggs 12 discuss the rela¬ 
tionship between coherence and syn¬ 
chronization. 

Memory management can be restruc¬ 
tured for DSM. A typical memory- 
allocation scheme (as in the C library 
malloc()) allocates memory out of a 
common pool, which is searched each 
time a request is made. A linear search 
of all shared memory can be expensive. 
A better approach is to partition avail¬ 
able memory into private buffers on 
each node and allocate memory from 
the global buffer space only when the 
private buffer is empty. 


R esearch has shown distributed 
shared memory systems to be 
viable. The systems described 
in this article demonstrate that DSM 
can be implemented in a variety of hard¬ 
ware and software environments: com¬ 
mercial workstations with native oper¬ 
ating systems software, innovative 
customized hardware, and even hetero¬ 
geneous systems. Many of the design 
choices and algorithms needed to im¬ 
plement DSM are well understood and 


integrated with related areas of com¬ 
puter science. 

The performance of DSM is greatly 
affected by memory-access patterns and 
replication of shared data. Hardware 
implementations have yielded enormous 
reductions in communication latency and 
the advantages of a smaller unit of shar¬ 
ing. However, the performance results 
to date are preliminary. Most systems 
are experimental or prototypes consist¬ 
ing of only a few nodes. In addition, 
because of the dearth of test programs, 
most studies are based on a small group 
of applications or a synthetic workload. 
Nevertheless, research has proved that 
DSM effectively supports parallel pro¬ 
cessing, and it promises to be a fruitful 
and exciting area of research for the 
coming decade. ■ 
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Transaction-Processing 
Systems 

Enrique Mafia and Bharat Bhargava, Purdue University 


Communication 
software is critical in 
distributed computing 
systems. This research 
identifies efficient 
mechanisms and 
paradigms for 
distributed transaction 
processing in a 
replicated database 
environment. 


D istributed transaction-processing systems must manage such functions as 
concurrency, recovery, and replication. One way to improve their effi¬ 
ciency and reliability is to increase software modularity, which means the 
separate components should execute in separate address spaces to permit hard¬ 
ware-enforced separation. This structure offers advantages but demands efficient 
interprocess communication (IPC) services. 

In our research at Purdue University, we are investigating mechanisms and 
paradigms for efficient communication support in conventional architectures, 
such as virtual-memory, single-processor machines with no special IPC hardware 
support. (Some mainframes have hardware assistance where more than one 
address space can be accessed at the same time.) 

We are studying communication designs in the context of the Raid system, a 
robust and adaptable distributed database system for transaction processing. 1 
Raid has been developed at Purdue on Sun workstations under the Unix operating 
system in a local area network. 

In Raid, each major logical component is implemented as a server, which is a 
process in a separate address space. Servers interact with other processes through 
a high-level communication subsystem. Currently, Raid has six servers for trans¬ 
action management: the user interface (UI), the action drive'r (AD), the access 
manager (AM), the atomicity controller (AC), the concurrency controller (CC), 
and the replication controller (RC). High-level name service is provided by a 
separate server, the oracle. 

Raid’s communication software, called Raidcomm, has evolved as a result of the 
knowledge we gained from other systems and from our own experiments, which 
are summarized in the following sections. The first version, Raidcomm V.l, was 
developed in 1986. Implemented on top of the SunOS socket-based IPC mecha¬ 
nism using UDP/IP (User Datagram Protocol/Internet Protocol), it provides a 
clean, location-independent interface between the servers. 2 To permit defining 
server interfaces in terms of arbitrary data structures, we used Sun’s external data 
representation standard, XDR. We developed Raidcomm V.2 in 1990 to provide 
multicasting support for the AC and RC servers. We designed Raidcomm V.3 to 
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support transmission of complex data¬ 
base objects. It is based on the explicit 
control-passing mechanism and shared 
memory. 

Related research work 

Research in operating systems, mul¬ 
tiprocessor systems, and computer net¬ 
works has made useful contributions to 
the field of communication facilities: 

• Carnegie Mellon’s Camelot proj¬ 
ect 34 identified communication sub¬ 
system requirements. 

• Remote procedure call (RPC)-based 
session services support the interaction 
among data servers and applications. 

• Highly specialized datagram-based 
communication facilities increase the 
performance demanded by data servers 
and applications. 

• Efficient local and remote IPC has 
been investigated in many distributed 
computing systems, for example, the V 
system, 5 Mach, 6 Amoeba, 7 Sprite, 8 and 
x-kernel. 9 

We classify the existing communica¬ 
tion paradigms into three groups: local 
interprocess communication, remote 
interprocess communication, and com¬ 
munication protocols for both local area 
and wide area networks. 

Local interprocess communication. To 

improve local machine performance, 
Bershad 10 introduced two new mecha¬ 
nisms: lightweight remote procedure call 
(LRPC) and user-level remote proce¬ 
dure call (URPC). LRPC takes advan¬ 
tage of the control transfer and commu¬ 
nication model of capability-based 
systems and the address-space-based 
protection model of traditional IPC fa¬ 
cilities. URPC, another cross-address- 


space communication facility, eliminates 
the role of the kernel as an IPC interme¬ 
diary by including communication and 
thread management code in each user 
address space. 

Both LRPC and URPC were imple¬ 
mented on a DEC SRC Firefly multi¬ 
processor workstation running the Tao 
operating system. 10 A simple cross-ad- 
dress-space call using SRC RPC takes 
464 microseconds on a single C-VAX 
processor. LRPC takes 157 microsec¬ 
onds for the same call, and using URPC 
reduces the call’s latency to 93 micro¬ 
seconds. 

We’ve found the ideas used in LRPC 
and URPC applicable in systems such 
as Raid. 

Remote interprocess communication. 

Several message-based operating sys¬ 
tems can reliably send messages to pro¬ 
cesses executing on any host in the net¬ 
work. The V system 5 implements address 
spaces, processes, and the interprocess 
communication protocol in the kernel 
to provide a high-performance message¬ 
passing facility. All high-level system 
services are implemented outside the 
kernel in separate processes. Mach 6 uses 
virtual-memory techniques to optimize 
local IPC. Remote communication goes 
through a user-level server process, 
which adds extra overhead. Amoeba 7 
uses capabilities for access control and 
message addresses. It has a small ker¬ 
nel, and most features are in user pro¬ 
cesses. 

However, not all the systems use the 
small-kernel approach with remote IPC 
outside the kernel. In Sprite, 8 the IPC is 
through a pseudodevice mechanism. 
Sprite kernel communication is through 
Sprite kernel-to-kernel RPC. RPC in x- 
kernel 9 is also implemented at the ker¬ 
nel level. Table 1 shows the performance 
of various RPCs over Ethernet. 


Table 1. Performance data for remote procedure calls. (The Sun 3/75 is a 2-MIPS 
machine, and the Sun 3/60 is a 3-MIPS machine.) 


System 

RPC Type 

Architecture 

Latency 

Latency by MIPS 

V 

User level 

Sun 3/75 

2.50 ms 

5.0 ms 

Mach 

User level 

Sun 3/60 

11.00 ms 

33.0 ms 

Amoeba 

User level 

Sun 3/60 

1.10 ms 

3.3 ms 

Sprite 

Kernel level 

Sun 3/75 

2.45 ms 

4.9 ms 

x-kernel 

Kernel level 

Sun 3/75 

1.70 ms 

3.4 ms 


Communication protocols. Commu¬ 
nication protocols provide a standard 
way to communicate between hosts con¬ 
nected by a network. Datagram proto¬ 
cols such as IP are inexpensive but un¬ 
reliable. However, more reliable 
protocols, such as virtual-circuit and 
request-response protocols, can be built 
on top of datagram protocols. 

The versatile message transaction 
protocol (VMTP) is a transport-level 
protocol that supports the intrasystem 
model of distributed processing. 5 Page- 
level file access, remote procedure calls, 
real-time datagrams, and multicasting 
dominate the communication activities. 
VMTP provides two facilities, stable 
addressing and message transactions, 
useful for implementing conversations 
at higher levels. A stable address can be 
used in multiple message transactions, 
as long as it remains valid. A message 
transaction is a reliable request-response 
interaction between addressable net¬ 
work entities (ports, processes, proce¬ 
dure invocations). Multicasting, data¬ 
grams, and forwarding services are 
provided as variants of the message 
transaction mechanism. 

Using virtual protocols and layered 
protocols, the x-kernel implements gen¬ 
eral-purpose yet efficient RPCs. 9 Virtu¬ 
al protocols are demultiplexers that route 
the messages to appropriate lower level 
protocols. For example, in an Internet 
environment, a virtual protocol will 
bypass the Internet Protocol for mes¬ 
sages originating and ending in the same 
network. The support of atomic broad¬ 
casting and failure detection within the 
communication subsystem simplifies 
transaction-processing software and 
optimizes network broadcasting capa¬ 
bilities. 11 For example, a two-phase com¬ 
mit protocol can be implemented by 
atomic broadcasting. 

Studies and 
enhancements 

We have conducted a series of exper¬ 
iments on the performance of the facil¬ 
ities available for building the Raid com¬ 
munication software. 212 

Experimental measurements and ob¬ 
servations. The measurements were 
done on Sun 3/50s (1-MIPS machines) 
that use the SunOS 4.0 operating sys¬ 
tem. We configured one workstation 
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Figure 1. Timing for a User Datagram Protocol send. 


with a special microsecond 
resolution clock to measure 
elapsed times. (This timer 
board, developed by Peter 
Danzig and Steve Melvin, 
uses Advanced Micro De¬ 
vices’ AM9513A timer chip. 

The timer has a resolution 
of up to four ticks per micro¬ 
second, and the overhead to 
read a time stamp is approx¬ 
imately 20 microseconds.) 

Our experimental work 
focused on general-purpose 
interprocess communication 
facilities, multicasting, and 
the impact of interprocess 
communication on distrib¬ 
uted transaction-processing 
performance. 

Communication. We mea¬ 
sured the overhead intro¬ 
duced by the layers of the socket-based 
interprocess communication model for 
datagram communication (UDP).These 
layers include the system call mecha¬ 
nism, the socket abstraction, communi¬ 
cation protocols (UDP, IP, and Ether¬ 
net), and interrupt processing. 

Figure 1 shows each layer’s contribu¬ 
tion to the total time of the send opera¬ 
tion of user-level messages. We found 
that the socket abstraction, which in¬ 
cluded copying the message between 
user and kernel spaces, was expensive. 
Starting the physical device required 
approximately 20 percent of the total 
send time. The peaks are due to the 
SunOS’s special memory allocation pol¬ 
icy. 12 

We investigated several mechanisms, 
including message queues, named pipes, 
shared memory synchronized by two 
semaphores, and UDP sockets in both 
the Internet and Unix domains. We mea¬ 
sured the round-trip time for a null mes¬ 
sage for each of these methods. We 
measured message queues at 1.7 milli¬ 
seconds, named pipes at 1.8 millisec¬ 
onds, shared memory with semaphores 
at 2.5 milliseconds, the Internet domain 
UDP socket at 4.4 milliseconds, and the 
Unix domain UDP socket at 3.6 milli¬ 
seconds. 

Multicasting. We studied several ap¬ 
proaches to multicasting. The first two 
alternatives are based on the Simple 
Ethernet (SE), a suite of protocols that 
provide low-level access to the Ether¬ 
net. 12 The user-level SE multicast utility 


is implemented on top of the SE device 
driver, which provides point-to-point 
Ethernet communication. The kernel- 
level SE multicast utility uses the multi- 
SE device driver. Finally, we experi¬ 
mented with physical multicasting. 
Although physical multicasting mini¬ 
mizes bandwidth, it demands a priori 
knowledge of the multicast address by 
all group members. This requirement 
may incur extra messages to set up the 
address. 

Impact. To observe the impact of Raid- 
comm V.l IPC on Raid’s transaction¬ 
processing performance, we ran the Deb- 
itCredit benchmark. 12 (Known as TP1 
or ET1, DebitCredit is a simple yet real¬ 
istic transaction-processing benchmark 
that uses a small banking database of 
three relations and 100-byte tuples.) The 
ratio of user times to system times for 
different servers is 2:1. Most of the sys¬ 
tem times are incurred by the communi¬ 
cation activities. 

Results. Details on the setup, proce¬ 
dures, and analysis of our experiments 
can be found elsewhere. 212 Below, we 
summarize only the major lessons and 
observations. 

• Expensive. General-purpose com¬ 
munication facilities are too expen¬ 
sive, 1012 even though many abstractions 
and mechanisms are useful to support a 
variety of applications and users. Mes¬ 
sages have to go through several unnec¬ 
essary layers of the communication sub¬ 


system. To overcome these 
problems, we recommend us¬ 
ing a simple IPC memory man¬ 
agement mechanism. Virtual 
and/or layered protocols in x- 
kernel and VMTP provide 
support to avoid such over¬ 
head. 

• Communication intensive. 
Transaction-processing sys¬ 
tems are communication in¬ 
tensive, 4 and most of the 
communication is local rath¬ 
er than remote. 10 If the local 
communication is handled as 
a particular instance of the 
remote case, the operating sys¬ 
tem kernel becomes the sys¬ 
tem bottleneck because of the 
high message traffic and the 
high cost to process messag¬ 
es. Communication facilities 
specialized for the local case 
can be simpler and more efficient. 

• Communication support. Some op¬ 
erating systems do not provide enough 
communication support for distributed 
transaction processing. The transaction¬ 
processing system implementer has to 
supply these services. It is desirable to 
define high-level interfaces between the 
modules. For communication, the mod¬ 
ules use typed messages rather than sim¬ 
ple buffers of bytes supported by the 
operating system. To be sent, a message 
has to be marshaled into kernel buffers. 
The receiving side must perform the 
inverse operation. 

• Multicasting. General-purpose mul¬ 
ticasting mechanisms require group ini¬ 
tialization and maintenance. In distrib¬ 
uted transaction processing, multicasting 
groups are typically dynamic and short 
lived. In this case, the overhead of group 
initialization can obliterate the perfor¬ 
mance advantages of multicasting. Our 
experiment shows that simulating mul¬ 
ticasting inside the kernel reduces CPU 
overhead. 12 Cheriton 5 has proposed mul¬ 
ticasting for many applications. We sug¬ 
gest that the group (multicasting) ad¬ 
dresses used during commitment time 
be established as a function of the unique 
transaction ID. This eliminates the need 
for extra messages to set up group ad¬ 
dresses. 

•Name resolution. Name resolution 
can become an expensive and compli¬ 
cated process. In general, we can have 
three different name spaces: applica¬ 
tion name space, interprocess commu¬ 
nication name space, and network name 
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Figure 2. Round-trip times in milliseconds. 


space. The Raid system uses 
a special protocol to map Raid 
names into interprocess com¬ 
munication addresses (UDP/ 

IP addresses). These address¬ 
es have to be mapped into 
network addresses (for ex¬ 
ample, Ethernet addresses) 
via a second address resolu¬ 
tion protocol. Fora local area 
network, a straightforward 
correspondence between log¬ 
ical and physical communi¬ 
cation addresses can be es¬ 
tablished. 

Enhancements. The Raid- 
comm V.2 implementation 
for local area networks em¬ 
ploys low overhead, simple 
naming, and transaction- 
oriented multicast support. 

Some of these ideas are based 
on LRPC and URPC. 10 Be¬ 
low, we briefly discuss ports, 
naming, multicasting schemes, and com¬ 
munication primitives. (Details can be 
found elsewhere. 12 ) 

Ports. Processes communicate through 
ports, which are the basic communica¬ 
tion abstraction. These ports reside in a 
memory segment shared by the process 
and kernel address spaces. Thus, data 
can be exchanged without copying. This 
method reduces copying by 50 percent 
compared with other kernel-based IPC 
methods. The mapped memory segment 
contains a transmission buffer and a set 
of receiving buffers. The number and 
length of these buffers are specified by 
a process at the time it opens a port. The 
receiving buffers form a circular queue, 
which is coherently managed by the 
kernel and the process according to the 
conventional producer/consumer para¬ 
digm. Associated with the transmission 
buffer and each of the receiving buffers 
is an integer, which specifies the actual 
length of the message. In addition, there 
is a counter for the number of active 
messages (messages that have arrived, 
but which the server has not yet pro¬ 
cessed). 

Naming. Within a given node, ports 
are uniquely identified by the triplet 
<Raid instance number, server type, 
server instances The other component 
of a Raid address, the site number or 
the transaction ID, determines the ad¬ 
dress of the physical node for monocast 


or the addresses of the group of nodes 
for multicast. In the case of Ethernet, 
we use only multicasting addresses for 
link-level communication. Site numbers 
or transaction IDs are used to build 
multicasting addresses by copying them 
into the four more-significant bytes of 
the Ethernet address. 

Multicasting. In physical multicasting 
for processing a given transaction’s data 
requests, each participant site sets a 
multicasting address using the transac¬ 
tion ID as its four more-significant bytes. 
At commitment time, the coordinator 
uses this address to multicast messages 
to all participant sites. This avoids the 
overhead of other multicasting meth¬ 
ods. Currently, multicast addresses are 
added or deleted by Raid servers. The 
RC adds a new multicasting address for 
a transaction when it receives the first 
operation request for that transaction. 
Under normal conditions, the AC de¬ 
letes the multicasting address once the 
transaction is committed or aborted. In 
the presence of failures, the CC does 
this job as part of its cleanup procedure. 
In the future, we plan to manage the 
multicasting addresses in the communi¬ 
cation subsystem. 

Communication primitives. System 
calls are provided to open and close a 
port, to send a message, and to add or 
delete a multicasting address. There is 
no need for an explicit receive system 


call. If idle, a receiving pro¬ 
cess must wait for a signal 
(and the corresponding mes¬ 
sage) to arrive. To send a 
message, a process writes it 
into the transmission buffer 
and passes control to the 
kernel. If the message is lo¬ 
cal, it is copied into a receiv¬ 
ing buffer of the target port, 
and the port’s owner is sig¬ 
naled (the owning process’ 
ID is stored in the port’s data 
structure). We use the Unix 
Sigio signal for this purpose. 
Otherwise, one of the exist¬ 
ing network device drivers 
sends the message to its des¬ 
tination. The send operation 
will be aborted if there are 
not enough receiving buff¬ 
ers. The destination address 
is constructed as described 
above, and the message is 
enqueued into the device’s 
output queue. When a message arrives 
over the network, it is demultiplexed to 
its corresponding port. Again, a signal 
alerts the receiving process about the 
incoming message. All this is done at 
interrupt time, so there is no need to 
schedule further software interrupts. 

Performance of the communication 
primitives. We measured the latency of 
a user-to-user round trip of local inter¬ 
process communication in Raidcomm 
V.l and V.2. In version 2 it is 1.4 milli¬ 
seconds, compared with the 4.4 milli¬ 
seconds of the UDP socket used in ver¬ 
sion 1. In version 1 the round-trip time 
increases by a 1-millisecond average for 
each kilobyte of data; in version 2 the 
round-trip time increases by 0.34 milli¬ 
second for each additional kilobyte. The 
latency of a user-to-user round-trip re¬ 
mote communication reduces from 5.1 
milliseconds in version 1 to 2.7 millisec¬ 
onds in version 2. The round-trip time 
increase for each kilobyte of data also 
reduces from about 3.0 milliseconds to 
2.5 milliseconds. (See Figure 2.) 

The socket-based IPC in version 1 
and the new communication facility in 
version 2 provide the same functional¬ 
ity in a local area network environment, 
and both are equally affected by signif¬ 
icant network device-driver overhead. 
Despite this fact, the new communica¬ 
tion facility achieves improvements of 
up to 50 percent. For multicasting, the 
performance advantages of the new com- 
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Figure 3. Performance of a context switch on the Sun 3/50 
running SunOS 4.0. 


munication facility become 
even more significant. The 
sending time does not depend 
on the number of destina¬ 
tions. On the other hand, the 
multicasting time for the 
socket IPC method grows lin¬ 
early with the number of des¬ 
tinations. 

Socket-based IPC does not 
optimize for the local case. 

Local round-trip costs are 68 
to 88 percent of those for 
remote round trips. In the 
new communication sub¬ 
system, local round-trip times are only 
35 to 50 percent of the corresponding 
remote round-trip times. 

Impact on transaction processing. We 

ran the DebitCredit benchmark on a 
single-site and a five-site system. For 
the five-site system, we used the ROW A 
(read-once, write-all) replication meth¬ 
od. This limited remote communication 
to the AC server. The benchmark con¬ 
tained 115 transactions that had write 
operations and required access to re¬ 
mote sites in the two-phase commit pro¬ 
tocol. Using Raidcomm V.2 reduced 
the system time for transaction process¬ 
ing by an average of 62 percent, bringing 
the user-time to system-time ratio to 3:1. 12 

Other issues. In Raidcomm V.3, we 
are addressing some problems with 
XDR, scheduling, and context switch¬ 
ing. 

XDR. New applications require the 
underlying communication subsystem 
to provide cheap transportation for com¬ 
plex data objects. The transmitted data 
structures are usually bounded linear 
buffers. We can build our local commu¬ 
nication channel in shared memory to 
avoid multiple encoding/decoding. Un¬ 
like lower level buffer-based communi¬ 
cation resources, which are one dimen¬ 
sional and usually accessible only as a 
whole, the shared memory segments 
are multidimensional, randomly ad¬ 
dressed storage resources just like the 
main memory. These schemes can elim¬ 
inate the overhead of XDR in local 
communication. 

Scheduling. Scheduling policies should 
consider high-level relationships that 
may exist among a group of processes. 
Conflicts may exist between the optimi¬ 
zation criteria at the operating system 


and application levels. The application 
should have some way to partially con¬ 
trol CPU allocation. The sender and the 
receiver process can collaborate under 
some high-level mechanism provided 
by the operating system to transfer the 
thread of control. In Unix, for example, 
the receiver process often goes to sleep 
to lower its priority. It is then put in a list 
and waits for the event (I/O, signals) 
that will grant it CPU time. 

Context switching. We also conduct¬ 
ed a series of experiments on context 
switching, based on the idea of explicit 
thread control passing. This is similar to 
the hand-off scheduling in Mach, but 
we’ve extended it to schedule ordinary 
processes in Unix. Figure 3 shows round- 
trip times for a context switch between 
two processes. Raidcomm V.3 uses an 
explicit control-passing mechanism and 
shared memory. This reduces the laten¬ 
cy of sending a high-level monocast Raid 
message to 0.68 millisecond. It was 2.4 
milliseconds in Raidcomm V.l, and 1.1 
millisecond in Raidcomm V.2. 


O verall, we have identified sev¬ 
eral communication services 
and mechanisms that can make 
Raid efficient. Separate address spaces 
can be used to structure a DTP system. 
High interaction among servers also trig¬ 
gers costly context-switching activity in 
the system. Increasing availability 
through distribution and replication of 
data demands special-purpose multicast¬ 
ing mechanisms. The idea of shared 
memory between the kernel and user 
processes is appealing, since it reduces 
context-switching activity. The identifi¬ 
cation of sites involved in transaction 
processing for accessing replicated data 
can be used in physical multicasting. 
Our work has studied Unix-like oper¬ 


ating systems. Obviously, 
Unix is not the only system 
on which commercial systems 
might be built, but it does 
provide a good benchmark 
for experimental study of 
new ideas in an academic 
setting. Our work has been 
conducted in a local area 
network environment. Simi¬ 
lar studies must be under¬ 
taken to identify and reduce 
the overhead in wide area 
networks. 

We believe communica¬ 
tions hardware and media technology is 
advancing at a rapid pace. Our research, 
along with related work in industry and 
academia, is intended to promote soft¬ 
ware advances. ■ 
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Distributed 
Database Systems: 
Where Are We Now? 


M. Tamer Ozsu, GTE Laboratories* 
Patrick Valduriez, INRIA 


If they live up to 
expectations, 
distributed DBMSs will 
replace centralized 
systems in many 
applications over the 
next few years. But 
some unsolved 
technical problems 
stand in their way. 

*Ozsu was on leave from the University of Alberta, 
Edmonton, Canada, during his work on this article. 


D istributed database technology is one of the most important computing 
developments of the past decade. During this period, distributed database 
research has been intense, culminating in the release of a number of first- 
generation commercial products. If it meets expectations, distributed database 
technology will impact data processing the same way centralized systems did a 
decade ago. Indeed, some observers claim that within the next 10 years most 
organizations will move toward distributed database managers, and centralized 
database managers will become an antique curiosity. 1 

With the technology now at the critical stage of finding its way into commercial 
products, it is important to seek answers to the following questions: 

(1) What were the initial goals and promises of distributed database technolo¬ 
gy? How do current commercial products measure up to these promises? In 
retrospect, were these goals achievable? 

(2) Have the important technical problems already been solved? 

(3) What technological changes underlie distributed data managers and how 
will they impact the next generation of systems? 

The last two questions hold particular importance for researchers because their 
answers determine the road map for research in coming years. Recent papers 
addressing these questions have emphasized scaling 2 and the introduction of 
heterogeneity and autonomy. 3 These problems are important, but many others 
remain unsolved. Even much-studied topics such as distributed query processing 
and transaction management involve research problems that have yet to be 
addressed adequately. Furthermore, new issues arise as the technology changes, 
application areas expand, and we gain experience with the application of distrib¬ 
uted database technology. 


What is a distributed database system? 

A distributed database is a collection of multiple, logically interrelated databases 
distributed over a computer network. 4 A distributed database management system 
(distributed DBMS) is the software system that permits the management of the 
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Figure 1. A distributed database environment. 


distributed database and makes the dis¬ 
tribution transparent to users. We use 
the term distributed database system to 
refer to the combination of the distribut¬ 
ed database and the distributed DBMS. 
The following assumptions about the 
system underlie these definitions: 

(1) Data is stored at a number of sites. 
Each site is assumed to consist logically 
of a single processor. Even if some sites 
are multiprocessor machines, the dis¬ 
tributed DBMS is not concerned with 
the storage and management of data on 
these machines. 

(2) The processors at sites are inter¬ 
connected by a computer network rath¬ 
er than a multiprocessor configuration. 
The important point here is the loose 
interconnection of processors that have 
their own operating systems and oper¬ 
ate independently. Although “shared- 
nothing” multiprocessor architectures 
are similar to loosely interconnected 
distributed systems, they involve differ¬ 
ent issues (such as task allocation and 
migration and load balancing) that are 
not considered in this article. 

(3) The distributed database is indeed 
a database, not a collection of files that 
can be stored individually at each net¬ 
work node. This marks a distinction 
between a distributed database and a 
distributed file system. To form a dis¬ 
tributed database, distributed data 
should be logically related according to 
some structural formalism, and access 
to data should be at a high level via a 
common interface. The typical formal¬ 
ism establishing the logical relationship 
is the relational model. In fact, most 
research on distributed database sys¬ 
tems assumes a relational system. 

(4) The system has the full function¬ 
ality of a DBMS. It is neither a distrib¬ 
uted file system nor a transaction-pro¬ 
cessing system. Transaction processing 
is not only one type of distributed appli¬ 
cation, but it is also among the functions 
provided by a distributed DBMS. How¬ 
ever, a distributed DBMS provides oth¬ 
er functions, such as query processing 
and structured data organization, that 
transaction-processing systems do not 
necessarily deal with. 

These assumptions are valid in to¬ 
day’s technology base. Most current dis¬ 
tributed systems are built on local area 
networks in which each site is a single 
computer. The database is distributed 
so that each site manages a single local 


database (Figure 1). Next-generation 
distributed DBMSs will be designed dif¬ 
ferently, however, as a result of techno¬ 
logical developments — especially the 
emergence of affordable multiproces¬ 
sors and high-speed networks. System 
design will also be affected by the in¬ 
creasing use of database technology in 
application domains that are more com¬ 
plex than business data processing and 
by the wider adoption of the client- 
server mode of computing, accompa¬ 
nied by the standardization of the cli¬ 
ent-server interface. Thus, the 
distributed DBMS environment will 
include multiprocessor database serv¬ 
ers connected to high-speed networks 
linking them and other data reposito¬ 
ries to client machines that run applica¬ 
tion code and participate in executing 
database requests. Distributed relational 
DBMSs of this type are already appear¬ 
ing, and several existing object-orient¬ 
ed systems also fit this description. 

A distributed DBMS as defined here 
is only one way of providing database 
management support for a distributed 
computing environment. We have de¬ 
vised a working classification of possi¬ 
ble design alternatives along three di¬ 
mensions 4 : 

• Autonomy refers to control distri¬ 
bution and indicates the degree to which 
individual DBMSs .can operate inde¬ 


pendently. It involves a number of fac¬ 
tors including whether the component 
systems exchange information,* wheth¬ 
er they can independently execute trans¬ 
actions, and whether one is allowed to 
modify them. Three types of autonomy 
are tight integration, semiautonomy, and 
full autonomy. In tightly integrated sys¬ 
tems, a single image of the entire data¬ 
base is available to users who want to 
share the information in multiple data¬ 
bases. Semiautonomous systems con¬ 
sist of DBMSs that can (and usually do) 
operate independently but have been 
designed to participate in a federation 
to make their local data shareable. In 
fully autonomous systems, however, the 
individual components are stand-alone 
DBMSs, which know neither of the ex¬ 
istence of other DBMSs nor of how to 
communicate with them. 

• Distribution^ deals with data. We 
consider two cases: Either data are phys¬ 
ically distributed over multiple sites that 
communicate with each other over some 
form of communication medium or they 
are stored at only one site. 

• Heterogeneity occurs in various forms 
in distributed systems, ranging from hard¬ 
ware heterogeneity and differences in 


*In this context, “exchange information” does not 
refer to networking concerns but to whether the 
DBMSs are designed to exchange information and 
coordinate their actions in executing user requests. 
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networking protocols to variations in data 
managers. The important forms of heter¬ 
ogeneity from the perspective of data¬ 
base systems are differences in data mod¬ 
els, query languages, interfaces, and 
transaction management protocols. The 
taxonomy classifies DBMSs as homoge¬ 
neous or heterogeneous. 

The alternative system architectures 
based on this taxonomy are illustrated 
in Figure 2. The arrows at the ends of 
the axes do not indicate an infinite num¬ 
ber of choices but simply the dimen¬ 
sions of the taxonomy. This article deals 
mainly with tightly integrated, distrib¬ 
uted, and homogeneous database sys¬ 
tems. 

Current state of 
distributed database 
technology 

Like any emerging technology, dis¬ 
tributed database systems have their share 
of fulfilled and unfulfilled promises. In 
this section, we consider the commonly 
cited advantages of distributed DBMSs 
and how well current commercial prod¬ 
ucts provide these advantages. 

Transparent management of distrib¬ 
uted and replicated data. Centralized 
database systems have taken us from a 


data processing paradigm in which data 
definition and maintenance were em¬ 
bedded in each application to one in 
which these functions are abstracted 
from the applications and placed under 
the control of a server called the DBMS. 
This new orientation results in data in¬ 
dependence — the immunity of appli¬ 
cation programs to changes in the logi¬ 
cal or physical organization of the data 
and vice versa. Distributed database 
technology is intended to extend the 
concept of data independence to envi¬ 
ronments in which data is distributed 
and replicated over a number of ma¬ 
chines connected by a network. Data 
independence is provided by several 
forms of transparency: network (and, 
therefore, distribution) transparency, 
replication transparency, and fragmen¬ 
tation transparency. Transparent access 
to data separates a system’s higher level 
semantics from lower level implemen¬ 
tation issues. Thus, database users would 
see a logically integrated, single-image 
database, even though it was physically 
distributed, enabling them to access the 
distributed database as if it were a cen¬ 
tralized one. In its ideal form, full trans¬ 
parency would imply a query language 
interface to a distributed DBMS no dif¬ 
ferent from that to a centralized DBMS. 

Most commercial distributed DBMSs 
do not provide a sufficient level of trans¬ 
parency. Part of the problem is a lack of 
support for replicated-data manage¬ 


ment. Some systems do not permit data 
replication across multiple databases; 
systems that do permit it require that 
the user be physically logged on to one 
database at a given time. Some distrib¬ 
uted DBMSs attempt to establish their 
own transparent naming schemes, usu¬ 
ally with unsatisfactory results, requir¬ 
ing the users either to specify the full 
path to data or to build aliases to avoid 
long path names. An important aspect 
of the problem is the lack of proper 
operating system support for transpar¬ 
ency. Network transparency can easily 
be supported by a transparent naming 
mechanism in the operating system. The 
operating system can also assist with 
replication transparency, leaving the task 
of fragmentation transparency to the 
distributed DBMS. 

Full transparency is not a universally 
accepted objective. Gray argues that 
full transparency makes distributed data 
management very difficult and claims 
that “applications coded with transpar¬ 
ent access to geographically distributed 
databases have poor manageability, poor 
modularity, and poor message perfor¬ 
mance.” 5 He proposes a remote proce¬ 
dure call (RPC) mechanism between 
requester users and server DBMSs 
whereby users would direct their que¬ 
ries to a specific DBMS. 

We agree that the management of 
distributed data is more difficult if trans¬ 
parent access is provided to users, and 
that the client-server architecture with 
RPC-based communication is the right 
approach. In fact, some commercial dis¬ 
tributed DBMSs are organized in this 
fashion (Sybase, for example). Howev¬ 
er, the original goal of providing trans¬ 
parent access to distributed and repli¬ 
cated data should not be abandoned 
because of the difficulties. The issue is, 
what should take over the responsibili¬ 
ty of managing distributed and replicat¬ 
ed data — the distributed DBMS or the 
user application? In our opinion, it 
should be the distributed DBMS, whose 
components can be organized in a cli¬ 
ent-server fashion. The related techni¬ 
cal problems are among the remaining 
research issues that must be addressed. 

Reliability through distributed trans¬ 
actions. Distributed DBMSs are intend¬ 
ed to improve reliability, since they have 
replicated components and thereby elim¬ 
inate single points of failure. The fail¬ 
ure of a single site, or a communication 
link failure that makes one or more sites 
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unreachable, is not enough to bring down 
the entire system.* In a distributed da¬ 
tabase, this means that some of the data 
may be unreachable, but with proper 
care, users may be permitted to access 
other parts of the database. This proper 
care comes in the form of support for 
distributed transactions. 

A transaction consists of a sequence 
of database operations, executed as an 
atomic action that transforms a consis¬ 
tent database state to another consis¬ 
tent database state, even when a num¬ 
ber of such transactions are executed 
concurrently (sometimes called concur¬ 
rency transparency), and even when 
failures occur (called failure atomicity). 
Therefore, a DBMS that provides full 
transaction support guarantees that con¬ 
current execution of user transactions 
will not violate database consistency in 
the face of system failures as long as 
each transaction is correct — that is, 
obeys the integrity rules specified for 
the database. 

Distributed transactions execute at 
multiple sites, where they access the 
local database. With full support for 
distributed transactions, user applica¬ 
tions can access a single logical image of 
the database and rely on the distributed 
DBMS to ensure that their requests will 
be executed correctly no matter what 
happens in the system. Correctly means 
that user applications need not be con¬ 
cerned with coordinating their accesses 
to individual local databases, nor need 
they worry about the possibility of site 
or communication link failures during 
execution of their transactions. There is 
a link between distributed transactions 
and transparency, since both involve 
distributed naming and directory man¬ 
agement. 

Providing transaction support requires 
the implementation of distributed con¬ 
currency control and distributed reli¬ 
ability protocols, which are significant¬ 
ly more complicated than their 
centralized counterparts. The typical dis¬ 
tributed concurrency control algorithm 
is some variation of the well-known two- 
phase locking (2PL) protocol, depend¬ 
ing on the placement of the lock tables 
and the assignment of lock manage¬ 
ment responsibilities. Distributed reli- 


site failures and link failures at this point. It is well 
known that link failures may cause network parti¬ 
tioning and are therefore more difficult to deal 
with. 


ability protocols consist of distributed 
commit protocols and recovery proce¬ 
dures. Commit protocols enforce atom¬ 
icity of distributed transactions by en¬ 
suring that a given transaction has the 
same effect (commit or abort) at each 
site where it exists, whereas recovery 
protocols specify how global database 
consistency is to be restored following 
failures. In the distributed environment, 
the commit protocols are two-phase 
(2PC) protocols. In the first phase, an 
agreement is established among the var¬ 
ious sites regarding the fate of a transac¬ 
tion. The agreed-upon action is taken in 
the second phase. 

Data replication increases database 
availability; copies of the data stored at 
a failed or unreachable site exist at oth¬ 
er operational sites. However, replica 
support requires the implementation of 
control protocols that enforce a speci¬ 
fied replica access semantics. The most 
straightforward semantics is one-copy 
equivalence, which can be enforced by 
the ROWA (read one, write all) proto¬ 
col. In ROWA, a logical read operation 
on a replicated data item is converted to 
one physical read operation on any one 
of its copies, but a logical write opera¬ 
tion is translated to physical writes on 
all copies. More complicated, less re¬ 
strictive replica control protocols, based 
on deferring the writes on some copies, 
have been studied but are not imple¬ 
mented in any systems we know of. 

Concurrency control and commit pro¬ 
tocols are among the two most studied 
topics in distributed database research. 
Yet their implementation in commer¬ 
cial systems is not widespread. The per¬ 
formance implications of implementing 
distributed transactions, which are not 
fully understood, make them unpopu¬ 
lar among vendors. Commercial systems 
provide varying degrees of distributed 
transaction support. Some (for exam¬ 
ple, Oracle) require users to have one 
database open at a given time, thereby 
eliminating the need for distributed 
transactions. Others (for example, Sy¬ 
base) implement the basic primitives 
necessary for the 2PC protocol but re¬ 
quire the user applications to coordi¬ 
nate the commit actions. In other words, 
the distributed DBMS does not enforce 
atomicity of distributed transactions but 
provides the basic primitives by which 
user applications can enforce it. Other 
systems, however, implement the 2PC 
protocols fully (Ingres and NonStop 
SQL, for example). 


Better performance. The case for the 
distributed DBMS’s superior perfor¬ 
mance is usually based on two points. 
First, a distributed DBMS fragments 
the conceptual database, enabling data 
to be stored in close proximity to its 
points of use. This feature, called data 
localization, has two potential advan¬ 
tages: (1) Since each site handles only a 
portion of the database, contention for 
CPU and I/O services is not as severe as 
for centralized databases, and (2) local¬ 
ization reduces remote access delays, 
which usually occur in wide area net¬ 
works (for example, the minimum round- 
trip message propagation delay in satel¬ 
lite-based systems is about 1 second). 
Most distributed DBMSs are structured 
to gain maximum benefit from data lo¬ 
calization. Full benefits of reduced con¬ 
tention and reduced communication 
overhead can be obtained only through 
proper fragmentation and distribution 
of the database. 

The second point in favor of the dis¬ 
tributed DBMS’s performance advan¬ 
tage is that the inherent parallelism of 
distributed systems can be exploited for 
interquery and intraquery parallelism. 
Interquery parallelism results from the 
execution of multiple queries at the same 
time. Intraquery parallelism is achieved 
by breaking up a single query into a 
number of subqueries, each executed at 
a different site, accessing a different 
part of the distributed database. 

If user access to the distributed data¬ 
base consisted only of querying (read¬ 
only access), then provision of interqu¬ 
ery and intraquery parallelism would 
imply that as much of the database as 
possible should be replicated. Howev¬ 
er, since most database accesses are not 
read-only, the mixing of read and up¬ 
date operations requires the implemen¬ 
tation of elaborate concurrency control 
and commit protocols. 

Today’s commercial systems employ 
two alternative execution models (oth¬ 
er than the implementation of full dis¬ 
tributed transaction support) to realize 
improved performance. The first alter¬ 
native is to have the database open only 
for queries (read-only access) during 
regular operating hours, while updates 
are batched. The database is then closed 
to query activity during off-hours, when 
the batched updates are run sequential¬ 
ly. This is time-multiplexing between 
read activity and update activity. The 
second alternative is based on multi¬ 
plexing the database: Two copies of the 
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database are maintained, one for ad hoc 
querying (called the query database) 
and the other for updates by application 
programs (called the production data¬ 
base). At regular intervals, the produc¬ 
tion database is copied to the query 
database. This alternative does not elim¬ 
inate the need to implement concurren¬ 
cy control and reliability protocols for 
the production database, since these are 
necessary to synchronize the write op¬ 
erations on the same data; however, it 
improves the performance of queries, 
since they can be executed without trans¬ 
action manipulation overhead. 

The performance characteristics of 
distributed database systems are not 
well understood. There are not enough 
true distributed database applications 
to provide a sound basis for practical 
judgments. In addition, performance 
models are not sufficiently developed. 
The database community has developed 
a number of benchmarks to test the 
performance of transaction-processing 
applications, but it is not clear whether 
they can be used to measure the perfor¬ 
mance of distributed transaction man¬ 
agement. The performance results of 
commercial DBMS products, even with 
respect to these benchmarks, generally 
are not openly published. NonStop SQL 
is one product for which performance 
figures, as well as the experimental set¬ 
up used in obtaining them, have been 
published. 

Easier, more economical system ex¬ 
pansion. In a distributed environment, 
accommodating increasing database siz¬ 
es should be easier. Major system over¬ 
hauls are seldom necessary; expansion 
can usually be handled by adding pro¬ 
cessing and storage power to the sys¬ 
tem. We call this database size scaling, 
as opposed to network scaling, which 
we discuss later. It may not be possible 
to obtain a linear increase in power, 
since this also depends on the distribu¬ 
tion overhead, but significant improve¬ 
ments are still possible. 

Microprocessor and workstation 
technologies have played a role in im¬ 
proving economies. Many commercial 
distributed DBMSs operate on mini¬ 
computers and workstations to take ad¬ 
vantage of their favorable price-perfor¬ 
mance characteristics. Moreover, most 
commercial distributed DBMSs oper¬ 
ate within local area networks, for which 
workstation technology is most suitable. 
The emergence of distributed DBMSs 


that run on wide area networks may 
increase the importance of mainframes. 
On the other hand, future distributed 
DBMSs may support hierarchical orga¬ 
nizations in which sites consist of com¬ 
puter clusters communicating over a 
local area network, with a high-speed 
backbone wide area network connect¬ 
ing the clusters. 

Another economic factor is the trade¬ 
off between data communication and 
telecommunication costs. In the previ¬ 
ous section, we argued that data local¬ 
ization improves performance by re¬ 
ducing delays. It also reduces costs. 
Consider an application (such as inven¬ 
tory control) that needs to run at sever¬ 
al locations. If this application accesses 
the database frequently, distributing the 
data and processing it locally may be 
more economical than executing the 
application at various sites and making 
remote accesses to a central database 
stored at another site. In other words, 
the cost of distributing data and ship¬ 
ping some of it periodically from one 
site to the other to execute distributed 
queries may be lower than the telecom¬ 
munication cost of frequently accessing 
a remote database. This part of the eco¬ 
nomics argument is still speculative. As 
we indicated above, most distributed 
DBMSs are local area network prod¬ 
ucts, and how they can be extended to 
operate in wide area networks is a topic 
of discussion and controversy. 


Unsolved problems 

In the previous section, we discussed 
the current state of commercial distrib¬ 
uted DBMSs and how well they meet the 
original objectives set for the technolo¬ 
gy. Obviously, the commercial state of 
the art still has a way to go. The situation 
is not only that commercial systems have 
to catch up with and implement research 
results, but that significant research prob¬ 
lems remain to be solved. 

Network scaling problems. As noted 
earlier, the database community does 
not have a full understanding of the 
performance implications of all the dis¬ 
tributed DBMS design alternatives. 
Specifically, questions have been raised 
about the scalability of some protocols 
and algorithms as systems become geo¬ 
graphically distributed 2 or as the num¬ 
ber of system components increases. 3 
One concern is the suitability of the 


distributed transaction-processing 
mechanisms (the 2PL and, particularly, 
the 2PC protocols) in distributed data¬ 
base systems based on wide area net¬ 
works. A significant overhead is associ¬ 
ated with these protocols, and 
implementing them over a slow wide 
area network may pose difficulties. 2 

Scaling issues are only part of a more 
general problem: We don’t have a good 
handle on the role of network architec¬ 
tures and protocols in distributed DBMS 
performance. Almost all the perfor¬ 
mance studies we know of assume a 
very simple network cost model, some¬ 
times so unrealistic as to use a fixed 
communication delay independent of 
all network characteristics such as load, 
message size, network size, and so on. 
The inappropriateness of these models 
can be demonstrated easily. Consider, 
for example, a distributed DBMS that 
runs on an Ethernet-type local area net¬ 
work. Message delays in Ethernet in¬ 
crease as network load increases and 
generally cannot be bounded. There¬ 
fore, realistic performance models of an 
Ethernet-based distributed DBMS can¬ 
not realistically use a constant network 
delay or even a delay function that does 
not consider network load. In general, 
the performance of the proposed algo¬ 
rithm and protocols in different local 
area network architectures is not well 
understood, let alone their comparative 
behavior in moving from local area net¬ 
works to wide area networks. 

The proper way to deal with scalabil¬ 
ity is to develop general, sufficiently 
powerful performance models, measure¬ 
ment tools, and measurement method¬ 
ologies. Such work has been going on 
for some time for centralized DBMSs 
but has not yet been sufficiently extend¬ 
ed to distributed DBMSs. We already 
raised questions about the suitability of 
existing benchmarks. Detailed and com¬ 
prehensive simulation studies do not 
exist either. Although there are plenty 
of distributed DBMS performance stud¬ 
ies, they usually employ simplistic mod¬ 
els, artificial work loads, or conflicting 
assumptions, or they consider only a 
few special algorithms. Making gener¬ 
alizations on the basis of existing per¬ 
formance studies requires a giant leap 
of faith. This does not mean we have no 
understanding of the trade-offs. In fact, 
certain trade-offs have long been recog¬ 
nized, and even the designers of earlier 
systems considered them. For example, 
the query processor of the SDD-1 sys- 
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tern was designed to execute distribut¬ 
ed operations most efficiently on slow 
wide area networks. Later studies con¬ 
sidered the optimization of query pro¬ 
cessors in faster, broadcasting local area 
networks. But these trade-offs can most¬ 
ly be spelled out only in qualitative terms; 
their quantification requires more re¬ 
search on performance models. 

Distribution design. Distributed da¬ 
tabase design methodology varies ac¬ 
cording to system architecture. For tight¬ 
ly integrated distributed databases, 
design proceeds top-down from require¬ 
ments analysis and logical design of the 
global database to physical design of 
each local database. For distributed 
multidatabase systems, the design pro¬ 
cess is bottom-up and involves the inte¬ 
gration of existing databases. In this 
section, we concentrate on the top-down 
design process. 

The step of interest to us in the top- 
down process is distribution design, 
which involves designing local concep¬ 
tual schemas by distributing global enti¬ 
ties over the sites of the distributed 
system. The global entities are specified 
within the global conceptual schema. In 
the relational model, both the global 
and the local entities are relations, and 
distribution design maps global rela¬ 
tions to local ones. The important re¬ 
search issue that requires attention is 
the development of a practical distribu¬ 
tion design methodology and its inte¬ 
gration into the general data-modeling 
process. 

The two aspects of distribution de¬ 
sign are fragmentation and allocation. 
Fragmentation is the partitioning of each 
global relation into a set of fragment 
relations. Allocation concentrates on 
the (possibly replicated) distribution of 
these local relations across the distrib¬ 
uted system’s sites. Research on frag¬ 
mentation has concentrated on hori¬ 
zontal (or selecting) and vertical (or 
projecting) fragmentation of global re¬ 
lations. Numerous allocation algorithms 
based on mathematical optimization 
formulations have also been proposed. 

No underlying design methodology 
combines the horizontal- and vertical¬ 
partitioning techniques; horizontal- and 
vertical-partitioning algorithms have been 
developed completely independently. If 
one starts with a global relation, there 
are algorithms to decompose it horizon¬ 
tally and algorithms to decompose it ver¬ 
tically into a set of fragment relations. 


It is extremely difficult to 
generalize on the basis of 
existing distributed DBMS 
performance studies. 


However, there are no algorithms that 
fragment a global relation into a set of 
fragment relations of which some are 
decomposed horizontally and others ver¬ 
tically. Researchers always point out that 
most real-life fragmentations would be 
mixed, that is, would involve both hori¬ 
zontal and vertical partitioning of a rela¬ 
tion; but research on how to accomplish 
this is lacking. We need a distribution 
design methodology that encompasses 
the horizontal- and vertical-fragmenta¬ 
tion algorithms and uses them as part of 
a more general strategy. Such a method¬ 
ology should take a global relation and a 
set of design criteria and come up with a 
set of fragments, some from horizontal 
and others from vertical fragmentation. 

Allocation, the second part of distri¬ 
bution design, is typically treated inde¬ 
pendently of fragmentation. The pro¬ 
cess, therefore, is linear; the output of 
fragmentation is input to allocation. At 
first sight, isolation of the fragmenta¬ 
tion and the allocation steps appears to 
simplify the formulation of the problem 
by reducing the decision space. Howev¬ 
er, closer examination reveals that iso¬ 
lating the two steps actually contributes 
to the complexity of the allocation mod¬ 
els. Both steps have similar inputs, dif¬ 
fering only in that fragmentation works 
on global relations whereas allocation 
considers fragment relations. They both 
require information about the user ap¬ 
plications (such as how often they ac¬ 
cess data and what the interrelationship 
of individual data objects is), but each 
ignores how the other uses these inputs. 

The end result is that the fragmenta¬ 
tion algorithms decide how to partition 
a relation partly on the basis of how 
applications access it, but the allocation 
models ignore the part this input plays 
in fragmentation. Therefore, the allo¬ 
cation models have to include all over 
again a detailed specification of the re¬ 
lationship among the fragment relations 
and how user applications access them. 
A more promising approach is to ex¬ 
tend the methodology discussed above 


so that it reflects the interdependence 
of the fragmentation and the allocation 
decisions. This approach requires ex¬ 
tensions of existing distribution design 
strategies (for example, see Ceri, Perni- 
ci, and Wiederhold 6 ). 

We recognize that integrated method¬ 
ologies such as the one we propose here 
may be complex. But combining these 
two steps may have synergistic effects 
enabling the development of acceptable 
heuristic solution methods. Some stud¬ 
ies give us hope that such integrated 
methodologies and proper solution mech¬ 
anisms can be developed. In these stud¬ 
ies, researchers build a simulation model 
of the distributed DBMS, taking as input 
a specific database design, and measure 
its effectiveness. Using such methods to 
develop tools that aid human designers 
rather than attempting to replace them is 
probably the appropriate approach to 
the design problem. 

Distributed query processing. Distrib¬ 
uted query processors automatically 
translate a high-level query on a distrib¬ 
uted database, which is seen as a single 
database by users, into an efficient low- 
level execution plan expressed on the 
local databases. Such translation has 
two important requirements. First, the 
translation must be a correct transfor¬ 
mation of the input query so that the 
execution plan actually produces the 
expected result. The formal basis for 
this task is the equivalence between 
relational calculus and relational alge¬ 
bra, and the transformation rules asso¬ 
ciated with relational algebra. Second, 
the execution plan must be optimal — 
that is, it must minimize a cost function 
that incorporates resource consumption. 
Thus, the query processor must investi¬ 
gate equivalent alternative plans to se¬ 
lect the best one. 

Because of the difficulty of address¬ 
ing these two aspects together, they are 
typically isolated ill two sequential steps: 
data localization and global optimiza¬ 
tion. 4 These steps are generally preced¬ 
ed by query decomposition, which sim¬ 
plifies the input query and rewrites it in 
relational algebra. Data localization 
transforms an input algebraic query 
expressed on the distributed database 
into an equivalent fragment query (a 
query expressed on database fragments 
stored at different sites), which can be 
further simplified by algebraic transfor¬ 
mations. Global query optimization gen¬ 
erates an optimal execution plan for the 
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input fragment query by making deci¬ 
sions regarding operation ordering, data 
movement between sites, and the choice 
of both distributed and local algorithms 
for database operations. Global optimi¬ 
zation gives rise to a number of prob¬ 
lems. These have to do with the restric¬ 
tions imposed on the cost model, the 
focus on a subset of the query language, 
the trade-off between optimization cost 
and execution cost, and the optimiza¬ 
tion-reoptimization interval. 

The cost model is central to global 
query optimization because it provides 
the necessary abstraction of the distrib¬ 
uted DBMS execution system in terms 
of access methods, and it provides an 
abstraction of the database in terms of 
physical schema information and relat¬ 
ed statistics. The cost model is used to 
predict the execution cost of alternative 
execution plans for a query. Important 
restrictions are often associated with 
the cost model, limiting the effective¬ 
ness of optimization in improving 
throughput. Work in extensible query 
optimization 7 is useful in parameteriz¬ 
ing the cost model, which can then be 
refined through experimentation. 

Although query languages are becom¬ 
ing increasingly powerful (for example, 
new versions of SQL), global query opti¬ 
mization typically focuses on a subset of 
the query language, namely select- 
project-join queries with conjunctive 
predicates. This is an important class of 
queries for which good optimization op¬ 
portunities exist. As a result, a good deal 
of theory has been developed for join 
and semijoin ordering. However, other 
important queries warrant optimization, 
such as queries with disjunctions, unions, 
fixpoints, aggregations, or sorting. A 
promising solution is to separate the lan¬ 
guage understanding from the optimiza¬ 
tion itself, which can be dedicated to 
several optimization modules. 

A trade-off is necessary between opti¬ 
mization cost and quality of the generat¬ 
ed execution plans. Higher optimization 
costs are probably acceptable to produce 
better plans for repetitive queries, since 
these plans will reduce query execution 
cost and amortize optimization cost over 
many executions. However, higher costs 
are unacceptable for ad hoc queries exe¬ 
cuted only once. Optimization cost is 
incurred mainly by searching the solu¬ 
tion space for alternative execution plans. 
In a distributed system, the solution space 
can be quite large because of the wide 
range of distributed execution strategies. 


Therefore, developing efficient strate¬ 
gies that avoid the exhaustive search ap¬ 
proach is critical. 

Global query optimization is typical¬ 
ly performed prior to execution of the 
query (hence, it is called static optimi¬ 
zation). A major problem with this ap¬ 
proach is that the optimization cost 
model may become inaccurate because 
of changes in fragment size or because 
of database reorganization, which is 
important for load balancing. The prob¬ 
lem, therefore, is to determine the opti¬ 
mal intervals of query recompilation 
and reoptimization, taking into account 
the trade-off between optimization and 
execution cost. 

Distributed transaction processing. It 

may be hard to believe that in an area as 
widely researched as distributed trans¬ 
action processing there are still impor¬ 
tant topics to investigate, but it is true. 
We have already discussed the scaling 
problems of transaction management 
algorithms. Additional topics include 
replica control protocols, more sophis¬ 
ticated transaction models, and nonse- 
rializable correctness criteria. 

In replicated distributed DBMSs, 
database operations are specified on 
logical data objects.* The replica con¬ 
trol protocols are responsible for map¬ 
ping an operation on a logical data ob¬ 
ject to an operation on multiple physical 
copies of this data object. In so doing, 
they ensure the mutual consistency of 
the replicated database. The ROWA 
rule discussed earlier is the most straight¬ 
forward method of enforcing mutual 
consistency. Accordingly, a replicated 
database is in a mutually consistent state 
if all copies of every data object have 
identical values. 

The field of data replication needs 
further research and experimentation 
on replication methods for computa¬ 
tion and communication and on the sys¬ 
tematic exploitation of application-spe¬ 
cific properties. Experimentation is 
needed to evaluate the claims made by 
algorithm and system designers, and we 
lack a consistent framework for com¬ 
paring competing techniques. One of 
the difficulties in quantitatively evalu¬ 
ating replication techniques is the ab¬ 
sence of commonly accepted failure in¬ 


*We use the term data object here instead of the 
more common data item because we do not want to 
make a statement about the granularity of the 
logical data. 


cidence models. For example, Markov 
models, sometimes used to analyze the 
availability achieved by replication pro¬ 
tocols, assume the statistical indepen¬ 
dence of individual failure events and 
the rarity of network partitions relative 
to site failures. We do not currently 
know that either of these assumptions is 
tenable, nor do we know how sensitive 
Markov models are to these assump¬ 
tions. Validation of the Markov models 
by simulation cannot be trusted in the 
absence of empirical measurements, 
since simulations often embody the same 
assumptions that underlie the Markov 
analysis. Thus, we need empirical stud¬ 
ies to monitor failure patterns in real- 
life production systems, with the pur¬ 
pose of constructing a simple model of 
typical failure loads. 

To achieve the twin goals of data 
replication — availability and perfor¬ 
mance — we need to provide integrated 
systems in which replication of data goes 
handinhandwith replication of compu¬ 
tation and communication (including 
I/O). Only data replication has been 
studied intensely; relatively little has 
been done in the replication of compu¬ 
tation and communication. Computa¬ 
tion replication has been studied in sev¬ 
eral settings, including the execution of 
synchronous duplicate processes as “hot 
standbys,” and the implementation of 
different versions of the same software 
to guard against human design errors. 
Replication of communication messag¬ 
es, primarily by retry, has been studied 
in the context of providing reliable mes¬ 
sage delivery, and a few papers report 
on the replication of I/O messages to 
enhance the availability of transaction¬ 
al systems. However, more study is need¬ 
ed of how these tools can be integrated 
with data replication to support such 
applications as real-time control sys¬ 
tems, which may benefit from all three 
kinds of replication. This work would 
be invaluable for guiding operating sys¬ 
tem and programming language design¬ 
ers in developing the proper set of tools 
to support fault-tolerant systems. 

In addition to replication, but related 
to it, we need more elaborate transac¬ 
tion models, especially models that ex¬ 
ploit application semantics to achieve 
higher availability and performance, as 
well as concurrency. As database tech¬ 
nology enters new application domains 
such as engineering design, software 
development, and office information 
systems, the nature and requirements 
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of transactions change. Thus, work also 
is needed on correctness criteria other 
than serializability. 

As a first approximation, transaction 
models can be classified along two di¬ 
mensions: the structure of transactions 
and the structure of objects that transac¬ 
tions operate on. Along the transaction 
structure dimension, we recognize flat 
transactions, closed-nested transactions, 
open-nested transactions such as sagas, 
and structures that include both open 
and closed nesting, in increasing order of 
complexity. Along the object structure 
dimension, we identify simple objects 
(such as pages), objects as instances of 
abstract data types, and complex objects, 
again in increasing complexity. We dis¬ 
tinguish the last two to indicate that ob¬ 
jects as instances of abstract data types 
support encapsulation (and therefore are 
harder to run transactions on than sim¬ 
ple objects) but do not have a complex 
structure (do not contain other objects), 
and their types do not participate in an 
inheritance hierarchy. 

Within this framework, most of the 
transaction model work in distributed 
systems has concentrated on the execu¬ 
tion of flat transactions on simple ob¬ 
jects. This point in the design space is 
well understood. While some work has 
been done in the application of nested 
transactions on simple objects, much re¬ 
mains to be done, especially in distribut¬ 
ed databases. Specifically, the semantics 
of these transaction models are still be¬ 
ing worked out. Similarly, work has been 
done on applying simple transactions to 
objects as instances of abstract data types 
and to complex objects. These are initial 
attempts that should be followed up to 
specify their full semantics, their incor¬ 
poration into a DBMS, their interaction 
with recovery managers, and their distri¬ 
bution properties. 

Complex transaction models are im¬ 
portant in distributed systems for several 
reasons. First, transaction processing in 
distributed multidatabase systems can 
benefit from the relaxed semantics of 
these models. Second, the new applica¬ 
tions that distributed DBMSs will sup¬ 
port in the future (such as engineering 
design, office information systems, and 
computer-assisted cooperative work) 
require transaction models incorporat¬ 
ing more-abstract operations that exe¬ 
cute on complex data. Furthermore, these 
applications have a sharing paradigm 
different from the typical database ac¬ 
cess we are accustomed to. For example, 



Distributed DBMSs require 
functions that existing 
distributed operating 
systems do not provide. 


computer-assisted cooperative work en¬ 
vironments require participants to coop¬ 
erate in accessing shared resources rath¬ 
er than to compete for them as is usual in 
database applications. These changing 
requirements necessitate the develop¬ 
ment of new transaction models and ac¬ 
companying correctness criteria. 

Integration with distributed operating 

systems. The undesirability of running a 
centralized or distributed DBMS as an 
ordinary user application on top of a host 
operating system has long been recog¬ 
nized. 89 There is a mismatch between the 
requirements of the DBMS and the func¬ 
tions of current operating systems. This 
is even more true in the case of distribut¬ 
ed DBMSs, which require functions that 
existing distributed operating systems do 
not provide — for example, distributed 
transaction support with concurrency 
control and recovery, efficient manage¬ 
ment of distributed persistent data, and 
more complicated access methods. Fur¬ 
thermore, distributed DBMSs necessi¬ 
tate modifications in how the distributed 
operating systems perform their tradi¬ 
tional functions (task scheduling, nam¬ 
ing, buffer management). In this section, 
we highlight the basic issues in distribut¬ 
ed DBMS-distributed operating system 
integration: system architecture, trans¬ 
parent naming of resources, persistent- 
data management, remote communica¬ 
tion, and transaction support. A more 
detailed discussion of the issues can be 
found in Chapter 13 of our book. 4 

An important architectural consider¬ 
ation is that the coupling of distributed 
DBMSs and distributed operating sys¬ 
tems is not a binary integration issue. 
The communication network protocols 
also must be considered, adding to the 
complexity of the problem. Thus, the 
architectural paradigm must be flexible 
enough to accommodate distributed 
DBMS functions, distributed operating 
system services, and communication 
protocol standards such as the ISO/OSI 
(Open Systems Interconnection) mod¬ 


el or the IEEE 802. In this context, 
efforts that include too many database 
functions inside the operating system 
kernel or those that modify tightly-closed 
operating systems are likely to prove 
unsuccessful. In our view, the operating 
system should implement only essential 
operating system services and only those 
DBMS functions that it can implement 
efficiently; then it should get out of the 
way. The model that best fits this re¬ 
quirement seems to be the client-server 
architecture with a small kernel that 
provides the database functions that can 
be provided efficiently and does not 
hinder the DBMS in efficiently imple¬ 
menting other services at the user level 
(examples are Mach and Amoeba). 
Object orientation may also have a lot 
to offer as a system structure to facili¬ 
tate this integration. 

Naming is the fundamental mecha¬ 
nism available to the operating system 
for providing transparent access to sys¬ 
tem resources. Whether or not access to 
distributed objects should be transpar¬ 
ent at the operating system level is a 
contentious issue involving the trade¬ 
off between data management flexibil¬ 
ity and ease of use on the one hand and 
system overhead on the other. For a 
distributed DBMS, transparency is im¬ 
portant. As we indicated earlier, many 
distributed DBMSs attempt to estab¬ 
lish their own transparent naming 
schemes without significant success. 
Further investigation of the naming is¬ 
sue and the relationship between dis¬ 
tributed directories and operating sys¬ 
tem name servers is needed. A 
worthwhile naming construct that de¬ 
serves some attention in this context is 
the capability concept, which was used 
in older systems such as Hydra and is 
being used in more modern operating 
systems such as Amoeba. 

Storage and management of persis¬ 
tent data — data that survives past the 
execution of the program that manipu¬ 
lates it — is the primary function of 
database management systems. Oper¬ 
ating systems have traditionally dealt 
with persistent data by means of file 
systems. If a successful cooperation par¬ 
adigm can be found, it may be possible 
to use the DBMS as the operating system 
file system. At a more general level, co¬ 
operation among programming languag¬ 
es, the DBMS, and the operating system 
to manage persistent data requires fur¬ 
ther research. Distributed file systems 
do not address distributed DBMS con- 
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cerns because either they do not provide 
for concurrent access to data or the gran¬ 
ularity of sharing is too large. 

Two communication paradigms that 
have been widely studied in distributed 
operating systems are message passing* 
and the remote procedure call. The rel¬ 
ative merits of these approaches have 
long been debated, but the simple RPC 
semantics (blocking, one-time execu¬ 
tion) have been appealing to distribut¬ 
ed system designers. As discussed earli¬ 
er, an RPC-based access to distributed 
data at the user level is sometimes pro¬ 
posed in place of fully transparent ac¬ 
cess. 5 But implementing an RPC mech¬ 
anism for a heterogeneous computing 
environment is not easy. The problem is 
that different vendors’ RPC systems do 
not interoperate. It may be necessary to 
view communication at higher levels of 
abstraction to overcome heterogeneity 
or at lower levels of abstraction (mes¬ 
sage passing) to achieve more parallel¬ 
ism. This trade-off needs further study. 

In current DBMSs, the transaction 
manager is implemented as part of the 
DBMS. Whether transactions should and 
can be implemented as part of standard 
operating system services has long been 
discussed. There are strong arguments 
on both sides, but a clear resolution of 
the issue requires more research as well 
as more experience with the various gen¬ 
eral-purpose (that is, non-DBMS) trans¬ 
action management services. 

Distributed multidatabase systems. 

Multidatabase system organization is 
an alternative to logically integrated dis¬ 
tributed databases. The fundamental dif¬ 
ference between the two approaches is 
the level of autonomy afforded the com¬ 
ponent data managers at each site. While 
integrated DBMSs’ components are de¬ 
signed to work together, multidatabase 
management systems consist of compo¬ 
nents that may have no notion of coop¬ 
eration. Specifically, these components 
are independent DBMSs, which means, 
for example, that although they may 
have facilities to execute transactions, 
they are incapable of executing distrib¬ 
uted transactions that span multiple com¬ 
ponents. In this section, we outline the 
open problems related to query pro¬ 
cessing and transaction management in 


*We are referring to logical message passing, not 
physical. Remote procedure calls must be trans¬ 
mitted between sites as physical messages as well. 


multidatabase systems. We also address 
the standardization issues and their role 
in interoperability. More detailed dis¬ 
cussion can be found in a special issue of 
ACM Computing Surveys. 10 

The autonomy and potential hetero¬ 
geneity of component systems create 
problems in query processing and espe¬ 
cially in query optimization. The basic 
problem is the difficulty of global opti¬ 
mization when local cost functions are 
not known and local cost values cannot 
be communicated to the multi-DBMS. 
It has been suggested that semantic op¬ 
timization based only on qualitative in¬ 
formation may be the best we can do, 
but semantic query processing is not 
fully understood either. It may be possi¬ 
ble to develop hierarchical query opti¬ 
mizers that perform some amount of 
global query optimization and then let 
each local system perform further opti¬ 
mization on the localized subquery. This 
may not provide an optimal solution 
but may enable some optimization. The 
emerging standards, which we will dis¬ 
cuss shortly, also may make sharing some 
cost information easier. 

The autonomy of the underlying 
DBMSs makes transaction processing 
in autonomous multidatabase systems 
more difficult. Since they are autono¬ 
mous, they have their own transaction¬ 
processing services (transaction man¬ 
ager, scheduler, recovery manager) and 
are capable of accepting local transac¬ 
tions and running them to completion. 
The multi-DBMS layer has its own trans¬ 
action-processing components, in charge 
of accepting and coordinating global 
transactions that access multiple data¬ 
bases. A global transaction is divided 
into subtransactions, each of which is 
submitted to one of the component 
DBMSs. However, since the multi- 
DBMS is not aware of the local transac¬ 
tions, it cannot control the local con¬ 
flicts, nor can it control indirect conflicts 
between global transactions caused by 
the interference of local transactions. 

Various solutions have been proposed 
to deal with concurrent multidatabase 
transaction processing. Some use glo¬ 
bal serializability of transactions as their 
correctness criteria; others relax serial¬ 
izability. Most of this work should be 
treated as preliminary attempts at un¬ 
derstanding and formalizing the issues. 
Many issues remain to be investigated. 
One area of investigation is revisions in 
the transaction model and the correct¬ 
ness criteria. Initial attempts have been 


made to recast the transaction model 
assumptions, and this work should con¬ 
tinue. The nested-transaction model 
looks particularly promising for multid¬ 
atabase systems, and its semantics, based 
on knowledge about the transaction’s 
behavior, need to be formalized. In this 
context, we should reconsider the mean¬ 
ing of consistency in multidatabase sys¬ 
tems. A good starting point is the four 
degrees of consistency defined by Gray. 8 

Another difficult issue that requires 
further investigation is the reliability 
and recovery aspects of multidatabase 
systems. The autonomy of individual 
DBMSs makes it difficult to incorpo¬ 
rate 2PC into global transaction pro¬ 
cessing, thus making it difficult to en¬ 
force distributed transaction atomicity. 
Although researchers have addressed 
the topic in recent studies, their ap¬ 
proaches are initial engineering solu¬ 
tions. Reliability and recovery proto¬ 
cols for multidatabase systems still need 
to be developed and integrated with 
concurrency control mechanisms. 

Autonomy is a major contributor to 
the additional complexity of multidata¬ 
base systems. One of the main impedi¬ 
ments to further development of these 
systems is the lack of understanding of 
the nature of autonomy. What we call 
autonomy is itself probably composed 
of several factors. Thus, the nature of 
autonomy must be clearly and precisely 
characterized. Furthermore, most re¬ 
searchers treat autonomy as if it were 
an all-or-nothing feature. Even the tax¬ 
onomy that we considered here indicat¬ 
ed only three points along this dimen¬ 
sion. But the spectrum between no 
autonomy and full autonomy probably 
contains many distinct points. It is es¬ 
sential, in our opinion, to (1) precisely 
define what is meant by “no autonomy” 
and “full autonomy,” (2) precisely de¬ 
lineate and define the many different 
levels of autonomy, and (3) identify the 
degree of database consistency possible 
for each level. At that point, it will make 
sense to discuss the different transac¬ 
tion models and execution semantics 
appropriate at each level. In addition, 
this process should enable the identifi¬ 
cation of a layered structure, similar to 
the ISO/OSI model, for the interopera¬ 
bility of autonomous and possibly het¬ 
erogeneous database systems. Such a 
structure would allow us to specify in¬ 
terfacing standards at different levels. 
Some work is already under way on the 
remote data access (RDA) standard. 
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and this line of work will make practical 
solutions to the interoperability prob¬ 
lem possible. 

Changing technology 
and new issues 

One of the common features of next- 
generation database systems is that they 
will need a data model more powerful 
than the relational model, without com¬ 
promising its advantages (data indepen¬ 
dence and high-level query languages). 
When applied to more complex appli¬ 
cations such as CAD/CAM, software 
design, office information systems, and 
expert systems, the relational data model 
exhibits limitations in terms of complex 
object support, type system, and rule 
management. To address these issues, 
two important technologies — knowl¬ 
edge bases and object-oriented data¬ 
bases — are being investigated. Anoth¬ 
er major issue is going to be system 
performance as more functionality is 
added. Exploiting the parallelism avail¬ 
able in multiprocessor computers is one 
promising way to provide high perfor¬ 
mance. Techniques designed for dis¬ 
tributed databases can be useful but 
need to be significantly extended to 
implement parallel database systems. 

Object-oriented database management 
systems (OODBMSs) combine object- 
oriented programming and database tech¬ 
nologies to provide greater modeling 
power and flexibility to programmers of 
data-intensive applications. 11 Over the 
last five years, OODBMSs have been the 
subject of intensive research and exper¬ 
imentation, which led to an impressive 
number of prototypes and commercial 
products. But the theory and practice of 
developing distributed OODBMSs have 
yet to be fully developed. Distributed 
environments will make the problems 
even more difficult. In addition, the is¬ 
sues of data dictionary management and 
distributed object management have to 
be dealt with. However, distribution is 
an essential requirement, since applica¬ 
tions that require OODBMS technology 
typically arise in networked workstation 
environments. The early commercial 
OODBMSs (for example, Gemstone) use 
a client-server architecture in which mul¬ 
tiple workstations can access the data¬ 
base centralized on a server. However, 
distributing an object-oriented database 
within a network of workstations (and 


Some issues can be 
simplified by relying on 
distributed relational 
database technology. 


servers) is becoming very attractive. In 
fact, some OODBMSs already support 
some form of data distribution transpar¬ 
ency (Ontos and Distributed Orion, for 
example). 

Knowledge base management systems 
try to make database management more 
intelligent by managing knowledge in 
addition to data. Capturing knowledge 
in the form of rules has been extensively 
studied in a particular type of knowl¬ 
edge base system called a deductive 
database. Deductive database systems 
manage and process rules specified over 
large amounts of data within the DBMS 
rather than in a separate subsystem. 
Rules can be declarative (assertions) or 
imperative (triggers). Rule management 
is essential, since it provides a uniform 
paradigm to deal with semantic integri¬ 
ty control, views, protection, deduction, 
and triggers. Much of the work in de¬ 
ductive databases has concentrated on 
the semantics of rule programs and on 
processing deductive queries, particu¬ 
larly in the presence of recursive and 
negated predicates. But much work is 
needed to combine rule support with 
object-oriented capabilities. For reasons 
similar to those for OODBMS applica¬ 
tions, knowledge base applications are 
likely to arise in networked workstation 
environments. These applications can 
also arise in parallel computing envi¬ 
ronments when the database is man¬ 
aged by a multiprocessor database serv¬ 
er (see next paragraph). In any case, we 
can simplify a number of issues by rely¬ 
ing on distributed relational database 
technology. Unlike most OODBMS 
approaches, which try to extend an ob¬ 
ject-oriented programming language, 
this similarity is a strong advantage for 
implementing knowledge bases in dis¬ 
tributed environments. Therefore, the 
new issues have more to do with distrib¬ 
uted knowledge management and pro¬ 
cessing and debugging of distributed 
knowledge base queries than with dis¬ 
tributed data management. 


Parallel database systems are designed 
to exploit recent multiprocessor com¬ 
puter architectures to build high-per¬ 
formance and fault-tolerant database 
servers. 12 For example, by fragmenting 
the database across multiple nodes, we 
can obtain more interquery and intraque¬ 
ry parallelism. For obvious reasons such 
as set-oriented processing and applica¬ 
tion portability, most of the work in this 
area has focused on supporting SQL. 
Discussion continues as to whether a 
shared-memory or a distributed-mem¬ 
ory multiprocessor architecture is more 
appropriate for data management. Res¬ 
olution of this question will require more 
experimental study. 

The design problems of parallel data¬ 
base systems, such as operating system 
support, data placement, parallel algo¬ 
rithms, and parallelizing compilation, 
are common to both kinds of architec¬ 
tures. If parallel data servers become 
prevalent, we can foresee an environ¬ 
ment in which several of them are placed 
on a backbone network, giving rise to 
distributed systems consisting of pro¬ 
cessor clusters. 5 An interesting concern 
in such an environment is internetwork¬ 
ing. Specifically, executing database 
commands that span multiple, and pos¬ 
sibly heterogeneous, clusters creates at 
least the problems that we discussed 
under distributed multidatabase systems. 
In addition, the queries must be opti¬ 
mized not only for execution in parallel 
on a cluster of servers, but also for exe¬ 
cution across a network. 


T he initial promises of distributed 
database systems —transparent 
management of distributed and 
replicated data, improved system reli¬ 
ability by means of distributed transac¬ 
tions, improved system performance by 
means of interquery and intraquery par¬ 
allelism, and easier and more economi¬ 
cal system expansion — are met to vary¬ 
ing degrees by today’s commercial 
products. Full realization of these prom¬ 
ises depends not only on commercial 
technology’s catching up with research 
results, but also on our solving a num¬ 
ber of problems. The following issues 
still require more work: 

(1) performance models, methodol¬ 
ogies, and benchmarks to better mea¬ 
sure the sensitivity of the proposed al¬ 
gorithms and mechanisms to the 
underlying technology; 
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(2) distributed query processing to 
handle queries more complex than se¬ 
lect-project-join, multiple query process¬ 
ing to save on common work, and opti¬ 
mization cost models to determine when 
such multiple query processing is bene¬ 
ficial; 

(3) advanced transaction models that 
differ from those defined for business 
data processing, better reflecting the 
processing mode (cooperative sharing, 
user interaction, long duration) com¬ 
mon in the applications distributed da¬ 
tabase technology is going to support; 

(4) analysis of replication and its im¬ 
pact on distributed database system ar¬ 
chitecture and algorithms, and devel¬ 
opment of efficient replica control 
protocols that improve system avail¬ 
ability; 

(5) distributed DBMS implementa¬ 
tion strategies that emphasize a better 
interface and cooperation with distrib¬ 
uted operating systems; 

(6) theoretically complete, correct, 
and practical design methodologies for 
distributed databases; and 

(7) the full set of problems related to 
the interconnection of autonomous in¬ 
formation-processing systems. 

The changing nature of the technolo¬ 
gy underlying distributed DBMSs will 
make parallel database servers feasible. 
This will affect distributed database 
systems in two ways. First, implement¬ 
ing distributed DBMSs on these paral¬ 
lel database servers will require revi¬ 
sion of most of the existing algorithms 
and protocols to operate on the paral¬ 
lel machines. Second, the parallel da¬ 
tabase servers will be connected as 
servers to networks, requiring the de¬ 
velopment of distributed DBMSs that 
will have to deal with a hierarchy of 
data managers. Furthermore, as dis¬ 
tributed database technology infiltrates 
nonbusiness data-processing domains, 
the capabilities required of these sys¬ 
tems will change, forcing a shift in 
emphasis from relational systems to more 
powerful data models. Current research 
along these lines concentrates on object- 
oriented and knowledge base systems. 

As we have seen, many important 
technical problems await solution, and 
new ones will arise as distributed data¬ 
base systems develop. These problems 
should keep distributed DBMS research¬ 
ers and implementers busy for some 
time to come. ■ 
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HyTime: A standard for structured hypermedia interchange 

Charles F. Goldfarb, IBM Almaden Research Center 


HyTime is being developed as an 
American and an international stan¬ 
dard (ISO/IEC 10744) for structured 
representation of hypermedia infor¬ 
mation. It is an application of ISO 
8879 (SGML) and is interchanged us¬ 
ing ASN.l (ISO 8824) for OSI com¬ 
patibility. HyTime complements and 
enhances the utility of standards for 
individual multimedia objects, such as 
motion video (MPEG) and still pic¬ 
tures (JPEG). This article introduces 
some of HyTime’s key concepts and 
facilities. 

What is hypermedia? Hypermedia 
is the union of two information pro¬ 
cessing technologies: hypertext and 
multimedia. Hypertext information is 
accessed in more than one order. Mul¬ 
timedia information is communicated 
by more than one means. 

Why HyTime? Were there only one 
hypermedia application that ran on 
only one platform, there would be no 
need for hypermedia representation 
standards. But this is not the case. 
There are thousands of hypermedia 
applications running on hundreds of 
platforms, each with its own method 
of representing the documents it pro¬ 
cesses. As a result, owners of hyper¬ 
media information find it difficult or 
impossible to interchange documents 
between these applications, or even to 
establish hyperlinks between docu¬ 
ments created by different applica¬ 
tions. (This, despite the fact that such 
links have existed in printed docu¬ 
ments for centuries in the form of bib¬ 
liographic references.) 

In spite of the diversity of applica¬ 
tions and platforms, interchange could 
still be achieved were it possible to 
create a standard representation for 
hypermedia documents that included 
the functions of all of the applications. 
Each application would simply con¬ 
vert between its own representation 
and the interchange form. Unfortu¬ 
nately, this goal is not fully achiev¬ 
able. Given the rate of technology 
change and new application develop¬ 


ment, plus the large capital and orga¬ 
nizational investments in specific ap¬ 
proaches, such a standard would be 
obsolete the day it was adopted — as¬ 
suming even that sufficient agreement 
for its adoption could be obtained. 

To paraphrase Abraham Lincoln: 
You can standardize some of the facil¬ 
ities for all of the applications, or all 
of the facilities for some of the appli¬ 
cations, but you can’t standardize all 
of the facilities for all of the applica¬ 
tions. 

The purpose of HyTime is to stan¬ 
dardize some of the facilities for all of 
the applications. In particular, it stan¬ 
dardizes those facilities having to do 
with the addressing of portions of hy¬ 
permedia documents and their com¬ 
ponent multimedia information ob¬ 
jects, including the linking, alignment, 
and synchronization that standardized 
addressing makes possible. 

HyTime does not standardize the 
data content notations (media formats 
or encodings), the encoding of the in¬ 
formation objects, or the application 
processing that is performed on them. 
Nor does HyTime standardize the 
overall document architectures, link 
types, or document type definitions. 
HyTime is an enabling standard, not 
an all-encompassing one. 

HyTime is able to provide a neutral 
base for the interchange of a variety 
of application-specific hypermedia in¬ 
formation in the same way that a 
linker in a programming system can 
provide a base for multiple compilers; 
that is, by dealing with the structure 
and identification of information ob¬ 
jects, rather than with their internal 
coding or processing semantics. Hy¬ 
Time provides a standard way to link 
to anything, anywhere, at any time. 

An analogy can be drawn between 
document interchange formats and 
automobiles: 

• Applications and document archi¬ 
tectures are like the bodies of cars: 
They determine the overall structure 
and appearance. Some formally stan¬ 
dardized examples are ODA, DSSSL, 


and SPDL. Some industry standards 
are CALS, CDA, and RFT:DCA. 

• The content notations are like the 
interior components of cars (seats, up¬ 
holstery, instruments, lights): They 
can be mixed and matched, and used 
with more than one body type. Some 
standard ones are CGM, MPEG, and 
JPEG. 

• HyTime is like the chassis of the 
car: It functions the same way regard¬ 
less of the body and interior mounted 
on it. 

Integrated open hypermedia. Hy¬ 
Time is a standardized infrastructure 
for the representation of “hyperdocu¬ 
ments” for integrated open hyperme¬ 
dia applications. A hyperdocument is 
a set of documents and other informa¬ 
tion objects connected by “webs” of 
links, each of which is connected to a 
“hub document.” (The term “docu¬ 
ment” is used here in the very general 
sense of “information intended for 
human perception.”) 

IOH follows the familiar “biblio¬ 
graphic model” of hyperlinking, 
wherein an author can link to any part 
of any document by an appropriate 
bibliographic reference (for example: 
“See the second drawing in Chapter 3 
of Dondeg, The Economics of Pub¬ 
lishing, Pennywise Press, Oxford, 
1904”). It is 

• integrated, because all information 
is linkable, whether or not it was spe¬ 
cially prepared for linking. 

• open, because the identification of 
the linked location (“addressing”) is 
not dependent on the file manage¬ 
ment or network architectures of par¬ 
ticular platforms. (There is a logical 
address, the bibliographic reference, 
that is not bound to a physical address 
— a page in a book on a shelf in a li¬ 
brary or bookstore — until the link is 
traversed and the “anchor” — the 
drawing — is accessed). 

• hypermedia, because it is both hy¬ 
pertext and multimedia. It is 
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Glossary 


ASN.1 

Abstract Syntax Notation 1 (ISO 8824) 

CALS 

Computer-aided Acquisition and Logistical Support (US Department of Defense) 

CDA 

Compound Document Architecture (Digital Equipment Corp.) 

CGM 

Computer Graphics Metafile (ISO 8632) 

DSSSL 

Document Style Semantics and Specification Language (ISO/IEC 10179) 

HyTime 

Hypermedia/Time-based Structuring Language (ISO/IEC 10744) 

IEC 

International Electrotechnical Commission 

IOH 

Integrated open hypermedia 

ISO 

International Organization for Standardization 

JPEG 

Joint Photographers’ Experts Group 

MPEG 

Motion Picture Experts Group 

ODA 

Office Document Architecture (ISO 8613) 

OSI 

Open Systems Interconnection 

REXX 

Programming language 

RFT:DCA 

Revisable Form Text: Document Content Architecture (IBM Corp.) 

SGML 

Standard Generalized Markup Language (ISO 8879) 

SMDL 

Standard Music Description Language (ISO/IEC 10743) 

SPDL 

Standard Page Description Language (ISO/IEC 10180) 


• hypertext, because 
the anchor (the 
picture) could link 
to a description in 
the text of 
Dondeg’s book, 
and that text could 
in turn link to an¬ 
other book, and so 
on. The reader can 
access the infor¬ 
mation in several 
ways. At each an¬ 
chor, the reader 
can either traverse 
the next link or 
continue reading 
sequentially. 

• multimedia , be¬ 
cause the first link 
began in character 
text (one medium) 
and led to a pic¬ 
ture (another me¬ 
dium). 

Many would cavil at the use of the 
term “multimedia” to describe the 
combination of character text and a 
still picture. But even if the docu¬ 
ments were represented electronically 
in a computer system, the character 
text was spoken, and the picture was 
an animation or video clip (conditions 
which to some people are implied by 
the term “multimedia”), the informa¬ 
tion structures would be unchanged 
and would work just as well. 

This is not to say there aren’t seri¬ 
ous and important technical issues in¬ 
volved in extending the bibliographic 
model to new (to the computer, at 
least) media such as sound and mo¬ 
tion video. But those issues have the 
same significance to the owner and 
user of the information as does the 
system’s ability to accomplish the 
physical access for a bibliographic ref¬ 
erence. That is to say, it’s critically im¬ 
portant that it work, but it has little 
impact on the logical structuring of 
the information base; the structure of 
juxtaposed characters and pictures is 
the same whether or not the pictures 
can move. 

Nevertheless, the technical prob¬ 
lems of new media impose serious 
constraints on today’s hypermedia ap¬ 
plications. In many cases, for example, 
a hyperdocument must be self- 
contained in a particular format on a 
CD-ROM for a particular platform. 
The hypermedia, in other words, is 
neither integrated nor open. Owners 
of information are therefore being 
asked to compromise between the real 
needs of their applications and the 
limitations of an emerging technology. 


Fortunately, this compromise need 
not require that hyperdocument data¬ 
bases be limited to today’s technol¬ 
ogy. Hypermedia is unusual for a new 
technology in that we know, in gen¬ 
eral, what its future will look like with 
respect to information representation: 
the same as its past. It is therefore 
possible to design a hyperdocument 
structuring language that will meet 
the requirements of an IOH future. 

At the same time, the design can be 
modular so that implementations need 
support only those facilities that are 
within their present capabilities. User 
investment in hyperdocument prepa¬ 
ration, however, would be encouraged 
because of the well-defined upward- 
compatible path to a full hypermedia 
solution. 

HyTime has been designed to satis¬ 
fy these requirements. 

The structure of HyTime. The con¬ 
nection between hypertext linking and 
multimedia time synchronization may 
not seem immediately obvious, but 
they are both applications of the same 
basic function: addressing. 

HyTime: the hypermedia part. The 
essential functional requirement of an 
IOH system is the ability to create a 
link to anything at all. A hyperdocu¬ 
ment representation that intends to 
support such systems must therefore 
have an appropriately powerful ad¬ 
dressing scheme. It must be able to 
address any arbitrary portion of any 
kind of information object, without 
requiring the ability to modify the ad¬ 
dressed object in any way. 


HyTime, as the standardized infra¬ 
structure for such hyperdocument 
representations, necessarily meets this 
requirement. The HyTime addressing 
model recognizes that only a few 
primitive addressing techniques exist. 
It supports these and provides combi¬ 
natorial facilities to build up complex 
chains and aggregates of locations 
that can be linked to as a single ad¬ 
dress. 

The HyTime forms of address are 

(1) By a unique name in a name 
space. For example, 

• A universally unique public identi¬ 
fier: Champion Rutherford’s Pride 
of Witheringham (Registered 
AKC*). 

• An equivalent locally unique 
name: Spot. 

(2) By a position on an axis in a co¬ 
ordinate system. For example, 

• The third house from the end of 
the street. 

• Next Wednesday at this time. 

• The second child of the first child 
of the root of the tree structure 
(and, by analogy, “his second 
grandchild by his oldest child”). 

• Ten minutes ago. 

(3) By a semantic construct. For ex¬ 
ample, 


* American Kennel Club, a standards organiza¬ 
tion of a different breed (so to speak) from those 
usually discussed in these pages. 
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• The book I read last week. 

• The lady in the red dress. 

• The world’s most beautiful cat. 

All three forms of address are re¬ 
quired for IOH: 

• Name space addressing is the basis 
of hyperlinking. It is the most robust 
form of address in that it can survive 
changes in the object being addressed. 

• Coordinate addressing is essential 
to scheduling, projection, alignment, 
and synchronization. It can be used 
for unnamed objects and arbitrary 
portions of objects. 

• Semantic addressing is necessary 
to provide addressability for arbitrary 
data. HyTime passes semantic ad¬ 
dresses to interpretation programs to 
convert to a name space or coordinate 
address. 

HyTime provides a complete 
schema for all three forms of address¬ 
ing and the ability to convert coordi¬ 
nate and semantic addresses to name 
space addresses so that all three can 
be linked uniformly. In addition, ap¬ 
plications and architectures have com¬ 
plete freedom to create higher forms 
of addressing, such as regular expres¬ 
sions or search queries that resolve to 
names or coordinate addresses. 

Access from the HyTime address of 
a location to its physical storage is 
provided by the SGML entity man¬ 
ager component of the system, which 
might invoke network processes to re¬ 
trieve the located data from a remote 
database. The process is analogous to 
the role of a reference librarian, who 
accesses a document mentioned in a 
citation either by locating it on the li¬ 
brary shelves, or by consulting a union 
catalog to find it in another library. 

HyTime: the time-based part. Hy- 
Time’s coordinate addressing is the 
foundation for event scheduling, 
alignment, and synchronization, all of 
which involve the manipulation of co¬ 
ordinate addresses. Synchronization 
can be represented, for example, by 

(1) Establishing a temporal unit 
(such as seconds) as the system of 
measurement for a coordinate axis; 
and 

(2) Specifying the address of one 
event as a function of the coordinate 
address of another event. 

The HyTime coordinate addressing 
model is a generalization of the time 
model originally developed for an¬ 
other standards project, ISO/IEC 
10743, the Standard Music Descrip¬ 


tion Language. SMDL, which is now 
an application of HyTime, is intended 
to foster the growth of applications 
that bring music into the information 
processing world, and that apply in¬ 
formation processing technology to 
the musical domain. For example: 

• Music publishing using modern 
text processing technology, including 
the integration of music with text and 
graphics. 

• Business presentations involving 
customized text, graphics, and music. 

• Computer-assisted instruction 
with music and sound effects em¬ 
ployed to enhance communication 
and to sustain the student’s interest. 

• Music education systems that 
sense the student’s performance, pro¬ 
vide feedback, and adapt the course 
materials to the student’s rate of 
progress. 

• Inclusion of musical performances 
and soft-copy “sheet music” as part of 
the product mix for electronic infor¬ 
mation distribution via teletext and 
videotex, as well as enhancement of 
nonmusical product (and advertise¬ 
ments) by musical accompaniment. 

To accomplish the objectives of the 
project, it was necessary to develop a 
model for the duration of events and 
their synchronization with one an¬ 
other. This model had to go beyond 
simplistic measurements of real time, 
such as those used in recording, to 
deal with the underlying abstract time 
(“music time”) that is expressed in the 
music from which the recording was 
made in the first place. The two kinds 
of time, abstract time and real time, 
are analogous to logical and layout 
structures in conventional documents 
(that is, unformatted and formatted). 

It became clear that the SMDL time 
model has applicability to multimedia 
and time-sequenced documents (for 
example, presentations) even when 
those documents have no purely musi¬ 
cal elements (for example, scores or 
gestural performances). For example, 
editing of time-based material today is 
highly labor-intensive, like the cut- 
and-paste techniques used in publish¬ 
ing prior to the advent of logical 
structure representation. 

Consider a video that includes a 
real-time animation of an internal 
combustion engine, along with other 
material. If the video is to be edited, 
say, to reduce its running time, human 
supervision is required to make sure 
that the duration of the real-time ani¬ 
mation is not altered. 

If modern document representation 
techniques were applied to the video. 


however, the structure would indicate 
not only the “formatted” duration in 
minutes, seconds, and frames, but also 
the underlying “unformatted” abstract 
time durations, which would indicate 
which portions could be varied. Com¬ 
puter programs could then attempt to 
scale the duration without affecting 
the real-time animation segment. 

HyTime provides this capability 
with its “event projection” module, 
which allows events in one coordinate 
space (such as one based in abstract 
time) to be projected onto another 
(such as one based in real time). The 
coordinate space and projection facili¬ 
ties deal equally well with space and 
time simply by changing the units of 
measure for the coordinate axes. 

An important benefit of this ap¬ 
proach is that the much richer projec¬ 
tion model of time (which was derived 
from music) can be applied in the spa¬ 
tial domain. Unlike typical spatial 
projection, where a single function is 
applied to the full extent of a coordi¬ 
nate axis, music projection, called 
“tempo,” allows the function to be 
changed from time to time (as it 
were). Moreover, the forms of specifi¬ 
cation of tempo can include refer¬ 
ences to other tempi, both absolute 
and relative values, and both precise 
and imprecise values. In HyTime, all 
the richness of the music time model 
is available in any measurement do¬ 
main. 

The music time model is about a 
thousand years old, and has been sta¬ 
ble for the past 300 or so, even in the 
face of dramatic innovations in music 
during that period. We can therefore 
have confidence that it is a mature, 
sophisticated, and flexible model for 
dealing with coordinate addressing 
and projection between coordinate 
spaces. 

Hence, the “time-based” part of 
HyTime refers not just to the informa¬ 
tion HyTime can describe (which is 
not limited to the time-based), but to 
the source of the descriptive capabili¬ 
ties, which are based on the centuries- 
old music time model. 


How HyTime is used. As stated pre¬ 
viously, HyTime, as an enabling stan¬ 
dard, is not a complete hyperdocu¬ 
ment architecture. Its functions will 
be incorporated into architectures and 
applications designed by standards 
committees, industry groups, and oth¬ 
ers. The HyTime language and inter¬ 
change format will be used to repre¬ 
sent and interchange these hyper¬ 
documents, in conjunction with other 
notations and standards. 
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The HyTime hyperdocument repre¬ 
sentation. An ideal interchange repre¬ 
sentation would be directly usable by 
a conforming system without transfor¬ 
mation. That is, the form in which the 
document is interchanged would also 
be the form in which it resides in a lo¬ 
cal file system until it is read by an ap¬ 
plication program and (temporarily) 
converted into an internal form. 

In most SGML applications today, 
the system- and application-indepen- 
dent interchange form is also the local 
file system form of a document and is 
read directly by applications. (There 
is no attempt to standardize internal 
forms, except to the extent that an ap¬ 
plication programming interface can 
be said to do so.) 

Hypertext and multimedia, how¬ 
ever, introduce considerations that 
tend to create a gulf between the in¬ 
terchange and local forms. A hyper¬ 
text application addresses not just a 
few documents at a time, but an entire 
library: the hyperdocument. Perfor¬ 
mance considerations of today’s plat¬ 
forms require that indexing and stor¬ 
age of those documents be highly 
optimized for the hypertext delivery 
system. Performance also dictates that 
the representation of multimedia 
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components, such as digital video and 
still graphics, depends heavily on the 
display architecture supported by the 
system. 

It has therefore been suggested 
that two kinds of interchange stan¬ 
dard will eventually exist: archival and 
delivery , the latter being the local file 
system form that is directly accessed 
by the hypermedia application. How¬ 
ever, as platform performance im¬ 
proves, more of today’s system-depen- 
dent information (such as indexes) 
will be represented in the interchange 
form. In other words, today’s archival 
interchange will evolve to delivery in¬ 
terchange; there will be no need to 
have both. Just as in SGML-based 
conventional document processing, 
the interchange and local forms will 
be the same. (The development of an¬ 
other international standard, SGML- 
13, a standardized binary encoding of 
parsed SGML documents optimized 
for hypertext access, should hasten 
this process.) 

Control flow. HyTime has been de¬ 
signed so that “HyTime engine” pro¬ 
grams can be implemented to perform 
address resolution, linking, alignment, 
and synchronization, thereby relieving 
application developers of these bur¬ 
dens. However, the standard does not 
impose a particular implementation 
architecture, and it is possible to inte¬ 
grate HyTime processing with appli¬ 
cation programs if desired. The Hy¬ 
Time architecture is modular, and 
only the facilities actually required 
need be implemented. 

The flow through a hyperdocument 
is controlled by an application pro¬ 
gram and is optionally modified by 
programs (usually called “scripts”) 
that occur as objects within the hyper¬ 
document. The application might ini¬ 
tially instruct the HyTime engine (or 
an equivalent integrated facility) to 
access objects sequentially, perform¬ 
ing whatever processing has been 
specified for them. If an object that is 
encoded in a data content notation is 
encountered, the application will typi¬ 
cally choose to call the program that 
can interpret the notation (for exam¬ 
ple, to display the image or perform 
the audio). If the notation is a script¬ 
ing language (HyperTalk, REXX, 
LinkWay, etc.,), the effect of “inter¬ 
preting the notation” is to execute the 
script. 

During script execution, user ac¬ 
tions or other external events could 
dictate a change in the path through 
the hyperdocument (for example, by 
traversing a link as a result of a user 
button press). 


Relationship to other standardiza¬ 
tion activities. Hypermedia/time- 
based documents show up in a num¬ 
ber of environments: 

• They can exist as a restricted hy¬ 
perdocument, with links allowed 
among its components, but not out¬ 
side (the case with most of today’s ex¬ 
isting multimedia applications, but un¬ 
acceptably limiting). 

• They can coexist with normal doc¬ 
uments, with links existing between 
the two kinds. 

• Hypermedia/time-based linking 
and synchronization can occur entire¬ 
ly within a single document. 

To accommodate this variety of 
uses, the information required for 
linking and synchronization must co¬ 
exist with the normal information for 
a document that is dictated by the ap¬ 
plication and/or architecture for which 
the document was created. 

Hypermedia, in other words, cannot 
be treated as a distinct form of infor¬ 
mation processing, but rather a series 
of extensions to existing activities in 
document processing, user interfaces, 
programming languages, networks, 
coding, and other areas. 

For example, document architec¬ 
tures will be extended to allow for the 
inclusion of hypertext links, new mul¬ 
timedia content types, and processing 
functions. There will likely be many 
such architectures — both standard¬ 
ized and application specific — ad¬ 
dressing the needs of different user 
communities. They will likely differ 
from one another in their support of 
specific scripting languages, data con¬ 
tent notations, and processing capabil¬ 
ities. 

Because of its inherent extensibility 
and its neutrality with respect to se¬ 
mantics, data types, and application 
policy, HyTime can serve as a com¬ 
mon infrastructure for such architec¬ 
tures, providing low-level linking and 
synchronization capability that in no 
way limits architectural rules regard¬ 
ing the types and uses of links. 


Further information. Several docu¬ 
ments on HyTime, including illustra¬ 
tive applications, are available from 
the SGML Users’ Group Special In¬ 
terest Group on Hypertext and Multi- 
media. Contact SGML SIGhyper, c/o 
Steven R. Newcomb, TechnoTeacher, 
Inc., 1810 High Rd., Tallahassee, FL 
32303-4408, phone, (904) 422-3574, 
fax (904) 386-2562, e-mail srn@cmr. 
fsu.edu. 
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Task Force on Computer-Based Systems Engineering holds first meeting 

Ashok K. Agrawala, Jonah Z. Lavi, and Stephanie White 


At its first meeting, the IEEE Com¬ 
puter Society Task Force on Comput¬ 
er-Based Systems Engineering refined 
the scope of the CB5E discipline, es¬ 
tablished appropriate working groups, 
and identified areas for future activi¬ 
ties. 

The recently established task force 
met May 13 in Austin, Texas, in con¬ 
junction with the 13th International 
Conference on Software Engineering 
and drew 32 people from Europe and 
the US representing industry, aca¬ 
demia, and government. 

Preliminary discussion. Task Force 
Chair Jonah Z. Lavi provided back¬ 
ground on the task force and summa¬ 
rized findings from the Neve Ilan 
workshop (see Computer, March 1991, 
pp. 105-107). In the subsequent group 
discussion, participants expressed the 
following opinions: 

(1) Current practice in the acquisi¬ 
tion, development, and evolu¬ 
tion of computer-based systems 
must be improved. 

(2) Such systems are often poorly 
engineered, requiring frequent 
reengineering and causing cost 
overruns. 

(3) There is often a mismatch be¬ 
tween system performance and 
customer expectations. Such 
confusion may also occur in the 
area of safety. 

Because the discipline includes a 
wide variety of activities performed 
by a diverse group of people, a major 
challenge facing the task force is to 
gather data about current work prac¬ 
tices, educational programs, and re¬ 
search activities. 

The meeting participants, while di¬ 
rectly involved in CBSE activities, 
represented only a fraction of the peo¬ 
ple in the field. Thus, others interest¬ 
ed in the activities are invited to get 
involved by providing information 
about their activities. 

Scope. An early focus of the meet¬ 
ing was defining the scope of CBSE. It 
is difficult to define the discipline con¬ 


cisely because it encompasses a vari¬ 
ety of systems, approaches, and prac¬ 
tices. However, the CBSE characteris¬ 
tics identified in the report from the 
Neve Ilan workshop provided a help¬ 
ful starting point. 

The discipline focuses on computer- 
based aspects of systems. This frame¬ 
work defines a narrower scope than 
that of systems engineering in general, 
which is concerned with the engineer¬ 
ing of the entire system. For example, 
nuclear power-plant control is a com¬ 
puter-based system, whereas the en¬ 
tire system includes the reactor, struc¬ 
tures, sensors, actuators, and so forth. 

The main feature of computer- 
based systems is that computers play a 
very significant role in the operation 
and control of these larger systems. 
Many such systems contain multiple 
computers that interact regularly, 
sharing information and carrying out 
sensing, communication, and control 
functions. As the assigned functions 
become more diverse, it is not uncom¬ 
mon to find heterogeneous comput¬ 
ers, each designed to perform a specif¬ 
ic task most efficiently. The extensive 
use of computers permits these sys¬ 
tems to carry out very complex func¬ 
tions that change over time. Such 
change requires that systems be up¬ 
graded regularly to keep pace with 
changing functions. 

Examples of typical computer- 
based systems include process control, 
computer-integrated manufacturing, 
large medical instrumentations, mili¬ 
tary and avionics systems, and large 
data-processing systems. 

Working groups. The task force es¬ 
tablished the following working 
groups: 

• the CBSE Education Working 
Group 

• the CBSE Research Working 
Group 

• the CBSE Practice Working 
Group 

CBSE education. The goal of this 
working group is to address all aspects of 
CBSE education and training, including 


a study of existing and planned educa¬ 
tional programs and the formulation of 
recommended curricula. 

There is a significant need for peo¬ 
ple trained in the CBSE discipline, 
both at the undergraduate and gradu¬ 
ate level. At present, only a few uni¬ 
versities have programs in this area. 
Several other educational institutions 
are formulating programs. Some of 
these programs are totally new; others 
leverage existing engineering pro¬ 
grams. 

The need for developing undergrad¬ 
uate and graduate curricula in CBSE 
is accompanied by a need for contin¬ 
ued professional education and train¬ 
ing. 

Raymond Buhr chairs this working 
group. He can be contacted at Carle- 
ton University, 1402-160 George St., 
Ottawa, Ont., Canada, KIN 9M2, 
phone (613) 788-5718, fax (613) 788- 
5727. 

CBSE research. This working group 
is intended to serve as a focal point 
for research-related issues in the disci¬ 
pline. Members will prepare a report 
on the state of research in the field; 
compile a bibliography of published 
papers, reports, and books; and identi¬ 
fy major research efforts, as well as 
problems needing attention. 

Several important research areas 
were identified at the meeting: 

• Most computer-based systems in¬ 
corporate a multicomputer environ¬ 
ment. The growth of complexity in 
such environments needs to be con¬ 
trolled as design proceeds. Tech¬ 
niques for permitting the scaling of 
designs on complex architectures pose 
many interesting research challenges. 

• Domain analysis methods are re¬ 
quired to specify the invarients and 
varying parameters for families of sys¬ 
tems. Better methods are needed for 
capturing system requirements (in¬ 
cluding behavior of the human-ma¬ 
chine interface) and for specifying sys¬ 
tem performance and dependability. 
Techniques are also needed for mod¬ 
eling the system environment and its 
interactions with the system. 
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• The CBSE discipline needs an 
appropriate mathematical founda¬ 
tion that will permit the study of de¬ 
signs and trade-offs based on the 
properties of components and archi¬ 
tectures. No actual or potential 
mathematical theories were identi¬ 
fied, however. New extensions to the 
chaos theory for discrete systems 
were suggested as a possible struc¬ 
ture, but such extensions are yet to 
be made. 

There are also many research is¬ 
sues related to methods used for sys¬ 
tem integration, prototyping, simula¬ 
tion, and modeling of 
computer-based systems. 

Hans Rischel chairs this working 
group. He can be reached at the De¬ 
partment of Computer Science, 
Technical University of Denmark, 
DTH, Building 347, 2800 Lyngby, 
Denmark, phone 45 (428) 81566, fax 
45 (428) 84530. 

CBSE practice. This working 
group plans to assess the state of 
practice in procurement and devel¬ 


opment of computer-based systems 
and recommend improvements. 

Several related ongoing efforts were 
identified. ESPRIT’s Complement 
project is investigating CBSE methods 
and tool use within the European 
Community. The ESPRIT Atmo¬ 
sphere project is examining the sys¬ 
tems engineering process. The US De¬ 
partment of Defense’s Software 
Engineering Institute has developed a 
software process assessment program 
that might be extended to CBSE. 

Ongoing standards work in the area 
includes the IEEE Systems Engineer¬ 
ing Management Standard (IEEE Std. 
1220), Systems Requirements Specifi¬ 
cation (IEEE Std. 1233), and a stan¬ 
dard under development by the Soci¬ 
ety of Automotive Engineers. 

The working group will collect in¬ 
formation and develop a report on 
problem areas. Suggestions and con¬ 
tributions should be forwarded to the 
group’s chair, Stephanie White, at 
Grumman Corp., MS All/25, Beth- 
page, NY 11714, phone (516) 575- 
9525, fax (516) 575-0667, e-mail 
steph@gdstech.grumman.com. 


CG&A columnist wins “genius” award 

Michael Haggerty, Staff Editor 

IEEE Computer Graphics and Applications 


James Blinn, award-winning com¬ 
puter graphics scientist, animator, and 
educator, recently added a $265,000 
grant to his list of honors. Blinn was 
among the 31 scientists, scholars, and 
artists who received this year’s gener¬ 
ous round of fellowships from the 
John D. and Catherine T. MacArthur 
Foundation. 

Blinn teaches computer graphics at 
the California Institute of Technology 
and also designs and narrates Project 
Mathematics!, a computer-animated 
series that teaches mathematical prin¬ 
ciples to high school students. Since 
1987, he has also been writing “Jim 
Blinn’s Corner” in IEEE Computer 
Graphics and Applications. In that 
column, he analyzes and explains 
computer graphics algorithms and 
techniques. 

In awarding Blinn the fellowship, 
the MacArthur Foundation stated 
that “in designing computer graphics, 
he [Blinn] works simultaneously as an 
artist, educator, mathematician, and 
scientist.” As a scientist at the Jet Pro¬ 
pulsion Laboratory from 1979 through 
1987, Blinn designed computer-ani¬ 


mated flybys of Jupiter, Saturn, and 
Uranus. He also created the anima¬ 
tion for Carl Sagan’s Cosmos. From 
1983 through 1986, he designed graph¬ 
ics for the Mechanical Universe 
project, rendering 550 scenes on the 
computer. Among those scenes were 
views of DNA replication and other 
natural phenomena. 

In 1983 Blinn was the first recipient 
of ACM SIGGraph’s Computer 
Graphics Achievement Award for his 
“major and significant contributions 
to the advancement of image synthesis 
algorithms and systems.” He holds BS 
degrees in physics and communication 
science, and an MSc in computer in¬ 
formation and control engineering, all 
from the University of Michigan, and 
a PhD in computer science from the 
University of Utah. 

Blinn will continue to work as the 
associate director of Project Mathe¬ 
matics! until the series is completed in 
1994. Although he reports having no 
definite plans for the grant money, he 
is considering developing an interac¬ 
tive educational program in biology or 
biochemistry. 


CBSE workshop. The task force 
will hold a workshop in the Washing¬ 
ton, DC, area in early spring, 1992. 
The working groups will present their 
findings, and CBSE methodologies 
and tools will be discussed. The work¬ 
shop’s findings will be published and 
forwarded to the IEEE Computer So¬ 
ciety. 

Further information. The task force 
is establishing a list of members and 
other interested parties. The material 
collected by the working groups and 
contributed by members will form a 
repository of information to be made 
available to anyone interested. 

To become a member, or to contrib¬ 
ute materials, ideas, or suggestions, 
contact Jonah Lavi, CBSE Chair, Isra¬ 
el Aircraft Industries Ltd., Corporate 
R&D, Embedded Computer Systems, 
Ben Gurion International Airport, Is¬ 
rael, phone 972 (3) 935-3716, fax 972 
(3) 935-8516; or Ashok Agrawala, 

Vice Chair, Department of Computer 
Science, University of Maryland, Col¬ 
lege Park, MD 20742, phone (301) 
405-2665, fax (301) 405-6707. 


Other 1991 fellows include David Do- 
noho, a statistician at Stanford Universi¬ 
ty; Sergiu Klainerman, a mathematician 
at Princeton; and James A. Westphal, a 
professor of planetary science at Caltech. 
Blinn is one of only two computer scien¬ 
tists (along with Donoho) to be honored 
with a MacArthur Fellowship this year. 

Although the MacArthur Fellow¬ 
ships are often referred to as the “ge¬ 
nius awards,” they are more precisely 
awards for creativity. “The creative 
person is at the heart of a society’s ca¬ 
pacity to improve the human condi¬ 
tion,” said MacArthur Foundation 
President Adele Simmons. “By sup¬ 
porting these fellows,.. . the founda¬ 
tion means to honor creative persons 
everywhere.” 

Applications are not accepted for 
MacArthur Fellowships. Instead, a 
group of more than 100 “designated 
nominators” from a variety of profes¬ 
sions all over the country submit 
names to a 12-member selection com¬ 
mittee. The committee’s choices must 
then receive approval from the foun¬ 
dation’s board of directors. There is 
no set number of fellowships, and 
there are no deadlines. 
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Nominees sought for Taylor Booth Award 


The Computer Society’s Taylor 
Booth Education Award Committee 
is seeking nominees for this year’s 
award. Nominations should explain 
the extent to which the nominee’s 
record fulfills each of the following 
four criteria: 

(1) Achieving recognition as a 
teacher of renown in a relevant 
and applicable course. 

(2) Writing an influential text in 
computer science and engineer¬ 
ing. 

(3) Leading, inspiring, or providing 
significant educational content 
during creation of a curriculum 
in the field. 


(4) Inspiring others to a career in 
computer sciences and engineer¬ 
ing education. 

The nominator should provide the 
following information about the nomi¬ 
nee in the order given (a vita may be 
included but not as a substitute for the 
information): name; current profes¬ 
sional employment affiliation(s) and 
title(s); mailing address; education, 
with institutions, degrees, year, and 
honors at graduation, if any; names 
and addresses of those expected to en¬ 
dorse the nomination; a brief citation 
indicating the nominee’s most salient 
qualifications for the award; the nomi¬ 
nee’s employment record and IEEE 
grade; and the nominee’s record of 


service to the Computer Society, oth¬ 
er societies, and the IEEE, particular¬ 
ly as it impacts the nominee’s educa¬ 
tional activities. 

A nominator should provide at least 
two endorsers for the nomination 
(maximum of five). In a letter to the 
committee chair, endorsers should 
evaluate the nominee on some or all 
of the four criteria given above. Any 
publications or references to the nom¬ 
inee’s published or professional work 
should be keyed to a specific criterion. 

All materials should be received by 
the Taylor Booth Committee chair, 
Oscar N. Garcia, George Washington 
University, 801 22nd St. NW, 6th 
Floor T-633, Washington, DC 20052, 
no later than October 1,1991. 


1991 Computerworld/ Smithsonian Award winners announced 


Three benefactor awards to indi¬ 
viduals and 10 awards to business, 
academic, and governmental organ¬ 
izations highlighted the 1991 
Computerworld /Smithsonian Awards 
ceremony in Washington, DC, June 
10. 

Gail Morse, a Christa McAuliffe 
Science Educator, received the Sie¬ 
mens Information Technology Lead¬ 
ership Award for Science Education. 
She was honored for pioneering a 
technology-intensive classroom to 
help students at risk of dropping out 
of school. Her students use comput¬ 
ers, laser videodiscs, microcomputer- 
based laboratories, and satellite com¬ 
munications. 

The Price Waterhouse Information 
Technology Leadership Award for 
Lifetime Achievement recognized 
Robert Noyce, a pioneer in the devel¬ 
opment of the integrated circuit. His 
innovations include microprocessors, 
erasable read-only memory, and dy¬ 
namic RAM. He lobbied vigorously in 
technical and political arenas to pro¬ 
mote US leadership in electronics. 
Noyce died last year at 62 (see Com¬ 
puter, July 1990, p. 92). 

Erich Bloch was named recipient of 
the MCI Communications Informa¬ 
tion Technology Leadership Award 
for Innovation. During the early 1960s 
Bloch helped develop the IBM/360 
family of computers. From 1984 
through 1990 he was director of the 
National Science Foundation, where 
he guided national programs in the 
sciences and engineering. 


Awards to organizations. Ten orga¬ 
nizations, each in a different category, 
were honored for their achievements: 

• Business and related services — 
Frito-Lay, for developing a hand-held 
computer that its sales force could use 
for gathering information that could 
be sent to the firm’s central computer. 

• Education and academia — the 
Lab School of Washington, where stu¬ 
dents with severe language deficits 
and other learning disabilities use 
multimedia tools on computers to 
construct stories from their inner ex¬ 
periences. 

• Environment, energy, and agricul¬ 
ture — Research Alternatives Inc., for 
an integrated system of computerized 
mapping, modeling, and communica¬ 
tions to help emergency managers 
plan for and respond to all types of 
natural and technological disasters. 

• Finance, insurance, and real estate 
— the Society for Worldwide Inter¬ 
bank Financial Telecommunication, 
for linking advanced information 
technology to create a network for 
transmitting essential data related to 
transactions between banks and other 
financial institutions. 

• Government and nonprofit orga¬ 
nizations — De Anza College, for a 
computerized network developed by 
the Bay Area Coalition for Employ¬ 
ment of Persons with Disabilities that 
shares information about job openings 
and training programs. 

• Manufacturing — Raychem-Ad- 
vanter, for using computer-aided de¬ 


sign and manufacturing to shorten 
product development time, and for us¬ 
ing computers to distribute informa¬ 
tion throughout the facility. 

• Media, arts, and entertainment — 
the Tenderloin Times, for using desk¬ 
top publishing to produce a monthly 
newspaper in four languages for vari¬ 
ous ethnic groups who share the same 
neighborhood. 

• Medicine — the Joint Center for 
Radiation Therapy and Stereotactic 
Radiosurgery, for new software that 
creates a three-dimensional map of a 
lesion and the surrounding brain tis¬ 
sue to help guide treatment. 

• Science — Next Computer, for 
Zilla, a program that draws on the 
computing power of workstations in a 
network to address large, challenging 
computing problems during users’ off- 
hours. 

• Transportation — United Parcel 
Service, for developing a computer¬ 
ized system that classifies tariffs, cal¬ 
culates taxes and duties, automates 
form preparation, and performs other 
tasks connected with international 
trade transactions. 


Sponsorship. The IEEE Computer 
Society is among the corporate spon¬ 
sors of the annual Computerworld/ 
Smithsonian Awards, a program es¬ 
tablished in 1989 to recognize 
achievement in the application of in¬ 
formation technology to the challeng¬ 
es of industry, society, and business. 
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Sixth International Parallel Processing Symposium 
Workshop on Heterogeneous Processing 
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The sixth annual International Parallel Processing Symposium (IPPS '92) will be held March 23-26,1992 at 
the Beverly Hilton, Beverly Hills, California. The symposium is sponsored by IEEE Computer Society and 
will be held in cooperation with ACM SIGARCH. IPPS '92 is a forum for engineers and scientists 
throughout the world to share current developments in all aspects of parallel and distributed processing. 

A workshop on Heterogeneous Processing (HP) will be held on the first day of the Symposium 
(March 23). This workshop is being sponsored by the Department of Energy. For the purposes of 
the workshop, HP is considered the use of different types of parallel processors, processing 
components, or connectivity paradigms to maximize performance, cost-effectiveness and/or 
development effort. HP might range in mode from coupled supercomputing-class machines at 
separated sites (aka "Metacomputing") to diverse elements in a single computer (aka mixed-mode 
processing). Components of Heterogeneous Processing have appeared in the scientific literature 
over the last several years. They have included such efforts as the matching of individual code 
segments to best-suited machines, the development of heterogeneous processor suites to span wide 
problem sets, and the intelligent management of heterogeneous processor suites. 

This is the first such workshop and the overall objective is to bring together as many potential HP 
interested groups as possible, including academic, government, and commercial efforts. The 
workshop will feature an invited address and several sessions of refereed papers demonstrating 
original research or significant case studies. The topics of interest include but are not limited to the 
following: 

Code Profiling Network Profiling 

Metacompilers Analytic Benchmarking 

Problem Mapping Intelligent Management 

Orchestration Tools Analysis Tools 

Configuration Levels and Modes Configuration Switching 

Crossover Strategies Processor Selection Criteria 

SUBMITTING PAPERS: All papers will be reviewed. Send five (5) copies of complete paper (not 
to exceed 15 single spaced, single sided pages). Manuscripts must be received by September 16, 

1991. Due to the large number of anticipated submissions, manuscripts postmarked later than 
September 15, 1991 will not be considered. (Post overseas submissions air mail.) Notification of 
review decisions will be mailed by December 13, 1991. Camera ready papers are due January 17, 

1992. Proceedings will be available at the symposium. Submit manuscripts to: 

Richard E Freund, Code 421 
Naval Ocean Systems Center 
San Diego, CA 92152-5000 

(voice) 619 553-4071, (fax) 619 553-6025, email: FREUND@NOSC.MIL 

In addition, participants at the Heteregeneous Processing Workshop might be interested in the 
following information from the IPPS '92 program. 


PARALLEL SVSTE3V*S FAIR 


As a new feature, IPPS '92 invites participation in a one day Parallel Systems Fair which will 
feature current parallel systems under development or available at academic, industrial and 
research lab sites. This opportunity is available for workshop participants as well. To be 
considered for inclusion in this program, submit a proposal (not to exceed 3 single spaced pages) to 
Commercial Exhibits Chair by November 1,1991. Submit proposals to: 


Mary Eshaghian 

Grumman Data Systems 

4015 Hancock Avenue, Suite 200 

San Diego, CA 92110-5154, email: mary@gdstech.grumman.com 
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NEW PRODUCTS 


Contact or send releases to Christine Miller, Computer, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264; Compmail, s.c. miller. 



Scientific graphics 
software improved 

Jandel Scientific’s SigmaPlot, used 
to create publication-quality charts 
and graphs on IBM PCs, is now in 
version 4.1, which uses 40 Kbytes less 
memory than version 4.0. It also in¬ 
creases font and output support, and 
automatically uses extended and ex¬ 
panded memory. The package pro¬ 
vides drop-down menus, user-defined 
options, an information status bar, ad¬ 
ditional curve-fit files, and improved 
documentation. 

SigmaPlot 4.1 is priced at $495. 
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Input from current SigmaPlot users 
resulted in drop-down menus and 
other improvements in version 4.1. 

Faster math 

Mathematica 2.0 from Wolfram Re¬ 
search has added 283 functions to 
those in Mathematica 1.2. Other im¬ 
provements include the ability to 
solve numerical differential equations, 
a performance increase (up to 20 
times faster execution of complex ex¬ 
pressions), publication-quality graph¬ 
ics, international character sets, file 
manipulation, and audio capabilities. 

Prices vary depending on the pro¬ 
gramming platform, starting at $595 
for the standard Macintosh version, 
ranging up to $30,000 for the Convex 
platform. Upgrades are from $125. 
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Users spy on data 

Spyglass Inc. has developed Trans¬ 
form, Dicer, and Format graphics 
packages to help users visualize sci¬ 
entific data. 

Transform 2.0 converts two-dimen¬ 
sional data into 2D color images and 
plots. It comes with a free utility 
package called View, which lets users 
display and manipulate color images, 
animate a sequence of images, and 
create new color tables. 

Dicer displays each 3D data set as 
a cube that may be freely rotated. 

The datacube may be sliced or por¬ 
tions diced away to reveal the interi¬ 
or of the solid. Differences in the 
data values are displayed as varia¬ 


tions in the color spectrum. This 
package is used to graphically depict 
data in fields such as geophysics, flu¬ 
id dynamics, electron microscopy, 
medical imaging, and computational 
chemistry. 

The Format add-on program com¬ 
plements Transform or Dicer by pro¬ 
ducing presentation-quality anima¬ 
tions and layouts. 

Transform 2.0, with the View utili¬ 
ty, lists for $495. Dicer 1.1 costs $495. 
(The Dicer 1.1 upgrade is free to reg¬ 
istered users of 1.0.) Format is avail¬ 
able for $195. 
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Differential equation solver for IBM PCs 


MicroMath Scientific Software’s 
ordinary differential equation solver, 
Diffeq, features drop-down menus, 
optional mouse support, and the 
ability to import/export Excel, Lo¬ 
tus, dBase, DIF, or ASCII files. Sev¬ 
en numerical model-solving methods 


are accepted; Episode, Runge-Kutta 
(IV), Adaptive Runge-Kuta, Predic¬ 
tor-Corrector, Modified Midpoint, 
Bulirsch-Stoer, and Euler. Plot types 
include time phase, time flow, phase 
field, and phase flow. The software 
also includes a comprehensive plot 


editor, the ability to handle data sets 
as large as the hardware will allow, 
and publication-quality hard-copy 
output via user-defined devices. 
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Help for character- 
based application 
development 

Ingres/Vision, a terminal-based ap¬ 
plication development tool from Ask 
Computer Systems, is a fourth-genera¬ 
tion language application code gener¬ 
ator that helps programmers to devel¬ 
op, and users to increase, the 
productivity of business applications. 

The two main components are the 
Frame Flow Diagram, which lets the 
programmer create the application 
structure in a form much like an orga¬ 
nizational chart, and the Visual Que¬ 
ry Editor, which defines the data to be 
accessed and the operations that will 
be made available. 

Besides simplifying programming 
functions, the software provides user 
interface features that include pictori¬ 
al representation of the application 
structure, menu navigation aids, con¬ 
text-sensitive help facilities, and pop¬ 
up dynamic selection lists for valid 
values. 

Ingres/Vision is immediately avail¬ 
able for the DEC VAX/VMS environ¬ 
ment, with prices ranging from $2,500 
to $120,000. Availability for other 
platforms is planned for later this 
year. 
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Device analysis 
environment 

Schlumberger/ATE Diagnostic Sys¬ 
tems Group’s IDE (Integrated Diag¬ 
nostic Environment) coordinates 
equipment and systems used in device 
analysis, including e-beam systems, 
microprobers, emission microscopes, 
and laser-cutting systems. Under 
workstation control, these systems are 
connected on a common Ethernet 
backbone. 

IDE has three major component 
functions: networking, which allows 
sharing of databases and use of identi¬ 
cal software and load modules; navi¬ 
gation, which permits the engineer to 
maintain a consistent understanding 
of the system; and paperless report 
generation, which sends images and 
waveforms directly into desktop pub¬ 
lishing. 

Availability of IDE is 90 days 
ARO, with a typical system starting at 
$40,000. 


Reader Service 40 


Security and safety 


Hardware, software 
virus protection 

Trend Micro Devices’ PC-cillin 
Version 3.0 includes a hardware “im- 
munizer” that attaches to the paral¬ 
lel port between the printer and 
computer system, as well as a soft¬ 
ware sensor device driver. Version 
3.0 offers three different configu¬ 
rable options with a choice of virus 
detection sensitivity levels. The sys¬ 
tem detects known and unknown vi¬ 
ruses, prevents their spread, quaran¬ 
tines new infected software, and 
provides damage recovery. It is com¬ 
patible with DOS versions 2.1 to 5.0, 
Windows 3.0, and most LAN envi¬ 
ronments. The system scans at 7 
Mbytes per minute and requires 8 
Kbytes of RAM. The cost is $139 
and site licenses are available. 
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Dockable and lockable 
CD-ROM 

Todd Enterprises’ TCDR 4000 
CD-ROM multidrive system has 
slips for up to four Hitachi TCDR 
3600 drives. Each drive can be sepa¬ 
rately installed, removed, replaced, 
and locked, allowing a single drive to 
be serviced without taking down the 
entire system. 

Specifications provided by the 
company include an access time of 
390 ms, 25,000 hours mean time be¬ 
tween failures, a 32-Kbyte buffer, 
variable voltage from 110 to 265V, 
two audio channels, and capacity for 
cable hookup to run a second bank 
of drives (up to eight drives total) on 
the same interface card. The four- 
drive system costs $4,195 (one-, two- 
and three-drive systems are also 
available). 

Reader Service 42 


Update services 
protect against new 
viruses 

Symantec Corp. has brought out 
version 1.5 of the Norton AntiVirus, 
which detects and eliminates over 
700 viruses and strains, including ap¬ 
plication, system, and boot infectors. 

The number of viruses is updated 
weekly as new definitions are added 
and made available to users through 
update services. Virus Intercept, a 
background scanner, can be config¬ 
ured to specifically meet user re¬ 
quirements. 

The company says that version 1.5 
scans twice as fast as the previous 
version and supports all major net¬ 
works. It is priced at $129, with free 
upgrades for registered users. 
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With the key locks turned, unautho¬ 
rized personnel cannot remove a CD 
disk, pull out a drive, or tamper with 
the power supply. 
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Reduced-emissions 

monitors 

Compaq has developed video 
graphics color and monochrome mon¬ 
itors that reduce ELF (extremely low 
frequency) and VLF (very low fre¬ 
quency) emissions, as well as electro¬ 
static potential on the face of the 
screen. The monitors comply with the 
recommendations of the Swedish Na¬ 
tional Board for Measurement and 
Testing 1990 documents. 

All VGA monitors from Compaq 
offer a 14-in. antiglare screen, up to 
640 x 480 resolution, adjustable 
brightness and contrast, integrated tilt 
and swivel, and noninterlaced scan¬ 
ning. 

Both video graphics color monitors 
support up to 256 colors simulta¬ 
neously for applications such as 
graphics-based spreadsheets and pre¬ 
sentation graphics. 

The video graphics monochrome 
monitor supports up to 64 shades of 
grey and is positioned for applications 
such as word processing, databases, 
spreadsheets, and basic desktop pub¬ 
lishing. 

The reduced-emissions color moni¬ 
tor is priced at $799 and the mono¬ 
chrome at $299. 


Surge protection for LANs 


Proxima Corp.’s LAN Pro Model 
S20LP, a surge and EMI/RF suppres¬ 
sor, is designed specifically for LAN 
(local area network) applications. 

According to the company, the unit 
delivers a maximum clamping of 296 
volts, with a 15-amp resettable circuit 
breaker, a surge failure audible alarm, 
six outlets, and a lifetime equipment 
protection policy. An HFA (high-fre¬ 


quency attenuator) filter eliminates 
most EMI/RF noise from 500 kHz to 
100 MHz, and a SHED (super high 
energy dissipation) circuit provides 
dissipation capability of 480 joules. 
The suppressor protects equipment 
against surges and spikes of up to 
6,000 volts and costs $79.95. 
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The company guar¬ 
antees that any 
computer equip¬ 
ment damaged due 
to power transients 
while properly con¬ 
nected to the LAN 
Pro will be re¬ 
paired or replaced 
free. 


Laptop security 
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PC smart card security 

Three PC security systems, Models 
10, 20, and 30 from Personal Comput¬ 
er Card Corp., let users choose levels 
of security. Common to all are the 
smart card and reader, which require 
the use of an encoded card and the 
knowledge of its contents to access se¬ 
cured data. These systems also inhibit 
piracy and viruses, and prevent unau¬ 
thorized browsing, alteration, or de¬ 
struction of files. The Model 20 cre¬ 
ates a log of all PC activity and 
provides boot protection. The Model 
30 provides DES encryption and de¬ 
cryption. Systems are IBM PC/XT/AT 
and PS/2 compatible, require 640 
Kbytes of memory, a hard disk, at 
least one floppy drive, and a serial 
port. 
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Personal Computer Card Corp.’s 
LapGuard uses a 3.5-in. floppy disk 
called KeyDisk to access secured 
machines. The company says this key 
cannot be counterfeited or duplicat¬ 
ed. An attempt to access the secured 
machine without the combination of 
KeyDisk and the user’s PIN (person- 


Stop Thief 

Pacific International has devel¬ 
oped Stop Thief, a burglar alarm for 
computers, printers, and other small- 
but-valuable stationary items. Once 
activated, the device sounds a loud 
alarm whenever movement is sensed 
and continues until the device ceases 
motion. 

The alarm can protect machines in 
office environments and dealers’ dis¬ 
plays. The price is $29.95. 
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al identification number) sets off an 
alarm. LapGuard can also encrypt 
files. Priced at $99, it can be used 
with portable, laptop, or notebook 
computers with DOS 3.0 or higher, a 
3.5-in. disk drive, and hard disk. 
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Stop Thief lets users protect their 
portable PCs. 
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DRAM and OTP memory cards 


Credit-card-sized memory cards 
from Texas Instruments provide in¬ 
creased speed and storage capabilities 
for applications where size, perfor¬ 
mance, and portability are important. 

The dynamic random access memo¬ 
ry card gives users a simple means of 
upgrading memory. It can be used in 
notebook/pocket computers as well as 
office equipment data memory, laser 
printer upgrades, and image memory. 

The one-time-programmable mem¬ 
ory cards simplify program storage. 
Typical applications include font stor¬ 
age for printers and program storage 


for equipment ranging from PC and 
facsimile machines to electronic cash 
registers and machine controllers. 

DRAM memory cards have access 
times of 60, 70, and 80 ns; OTP memo¬ 
ry cards, 200 ns. Operating on low 
standby current, these cards can sup¬ 
port 8-, 16-, and 32-bit processors. 

The standard DRAM 1-Mbyte card 
costs $340, and OTP cards are priced 
from $73 for a 64-Kbyte memory to 
$160 for 512 Kbytes, with high-density 
cards available soon. 
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TI’s 1-Mbyte DRAM card can expand 
memory in systems typically limited 
by their physical size. 



Entry-level system for math-intensive applications 


Leading Edge’s D2/Plus, a 286- 
based system with the Intel processor 
operating at 12 MHz, supports an 
80287 math coprocessor. The standard 
1-Mbyte memory is expandable to 
4 Mbytes on the motherboard and to 
16 Mbytes on the total system. 


Offered in three configurations, the 
basic D2/Plus includes 1 Mbyte of 
RAM, a 1.2-Mbyte 5.25-in. floppy 
drive, a 101-key keyboard, MS-DOS 
3.3, GW-Basic, and Microsoft Works. 
The basic D2/Plus is priced at $895. 

The second configuration adds a 


1.44-Mbyte 3.5-in. floppy drive and 
VGA controller, costing $1,095. 

The third configuration has a 40- 
Mbyte hard drive and costs $1,495. 


Visualize 

The 

Possibilities 

Three New 
Journals from 
Academic 
Press 


Computer Vision, Graphics, and Image Processing 

is expanding into two publications in 1991: 


Editors-in-Chief 
Norman Badler 

University of Pennsylvania, 
Philadelphia 

Rama Chellappa 

University of Southern 
California, Los Angeles 


Volume 53 (1991), 6 is: 


CVGIP: Graphical Models and Image Processing 

Area Editors: Brian A. Barsky, Gabor Herman, R.L. Kashyap, Nelson Max, 
Arun N. Netravali, Franco P. Preparata, Aristides A. Requicha, 

Demitri Terzopoulos, John W. Woods 
CVGIP: Graphical Models and Image Processing focuses on the synthesis 
methods and computational models underlying computer-generated or 
-processed imagery. 

ISSN 1049-9652 In the U.S.A. and Canada: $200.00 All other countries: $237.00 


Sample copies and privileged 
personal rates are available 
upon request. 

For more information, please 
write or call: 


ACADEMIC 
PRESS, INC. 

Journal Promotion 
Department 
1250 Sixth Avenue 
San Diego, CA 
92101, U.S.A. 

(619) 699-6742 

All prices are in U.S. dollars 
and are subject to change 
without notice. 

SI0260 


Editor-in-Chief CVGIP: Image Understanding 

Linda G. Shapiro Area Edjt ors: Ruzena K. Bajcsy, Larry S. Davis, Herbert Freeman, 

Washington Seattle Robert M. Haralick, Thomas S. Huang, Ramesh Jain, Edward Riseman, 

Azriel Rosenfeld, Hanan Samet, Steven L. Tanimoto 

The central focus of this journal is the computer analysis of pictorial 
information. CVGIP: Image Understanding publishes papers covering all 
aspects of image analysis from the low-level, iconic processes of early vision 
to the high-level symbolic processes of recognition and interpretation. 

Volumes 53-54 (1991), 6 issues ISSN 1049-9660 In the U.S.A. and Canada: $264.00 All other countries: $302.00 

New in Journal of Visual Communication and 
1990 Image Representation 

This new journal publishes papers on the state-of-the-art of visual com¬ 
munication and image representation with emphasis on novel technologies 
and theoretical work in this multidisciplinary area of pure and applied 
research. 


ISSN 1047-3203 In the U.S.A. and Canada: $128.00 All other countries: $154.00 


Editors-in-Chief 
Yehoshua Y. Zeevi 

Technion-lsrael Institute of 
Technology, Haifa and CAIP 
Center, Rutgers University, 
Piscataway, New Jersey 

T. Russell Hsing 

Bell Communications 
Research, Morristown, 

New Jersey 

Volume 2 (1991), 4 issues 
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ADVANCE INVITATION TO 


E S E C 9 1 
THIRD EUROPEAN 

SOFTWARE ENGINEERING CONFERENCE 


with free admission to 

CQS 9 1 

Fifth european observatory on Software Engineering: 
CASE and Software Quality 


Milan (Italy) , October 21 - 24, 1991 - Centro Cong r essi Milanofiori 




ESEC 91 (European Software Engineering Conference) is the third edition 
ofacydeof conferences which hasnowbecomearegular date for professional 
and researchers interested in the most recent research activities in the 
Software Engineering field. 

Researchers, developers and users from both the academic and the indu¬ 
strial world meet to share experiences, evaluate results and explore new 
ideas which can contribute to improving the quality and cost-effectiveness 
of the software production process. 

ESEC is organized every two years under the supervision of a committee 
which groups together the representative of six national computer societies 
operating in Europe: ATI for Spain, AFCET for France, SI for Switzerland, 
GI for Germany, BCS for Great Britain and A1CA for Italy. 

The articles submitted to the program committee have been more than 130, 
coming from european, american and asian countries: of these, 22 have been 
selected and will presented during the conference. The conference program 
foresees also 4 tutorials, 3 panels, and 6 invited speakers, who will provide 
valuable insights and evaluations on relevant issues of the software engi¬ 
neering field. This third edition of ESEC will be held in conjunction with 


other two important events: CQS 91 and the Sixth IEEE International 
Workshop on Software Specification and Design (IWSSD 6). 

CQS is the most important annual event organized in Italy regarding 
problems of software quality and productivity, and has now reached its 
Fifth edition. Organized for the first time in 1987 under the title of "Italian 
Software Quality Observatory", the CQS met with immediate success, 
highlighted by the high number of participants (700 in 1987, more than 
2,000 in 1988 and more than 3,000 in 1989 and 1990). The CQS is a non profit¬ 
making event financed by a large number of Sponsors, both users and 
suppliers of EDP and software technologies. 

The large numbers of highly qualified participants have always made the 
CQS the most important "shop-window" for the presentation of products 
and services forCASE, and many suppliers now tend to focus the campaigns 
for presenting their new CASE products on the CQS. 

ESEC attendees will have free admission to all the initiatives of CQS 91. 
IWSSD 6, the sixth International Workshop on Advanced Techiniques for 
the Specification and Design of software, will be held in Como on 25th and 
26th October, just after the conclusion of ESEC 91. 


Welcome to Milano 

Milano, one of themostdynamicandmoderndty in Europe, wishes to welcome and host you for this international week on software engineering. 
During your stay, you will appreciate the many attractions that such an intriguing city can offer you: art, music, culture, cousine and, close to 
the city, the Lakes and the Alps. Milano is also not far from Venice, Florence and the Riviera. 

Hotel booking info 

Deposit request for hotel booking is: Lit. 100.000. For each person the deposit includes Lit. 20.000 for agency booking service non refondable. 
Payment should be made in italian currency (bank transfer option is preferred) to: 

• Bank cheque payable to: ETNOTEAM SpA 

• Bank wire transfer: BANCA POPOLARE DI MILANO - Agency 9 - C.so B. Aires, 79 Milano - Account Nr. 10367 ETNOTEAM 

• Credit Card 

A voucher for the deposit and a confirmation of the reservation with name and address of the hotel will be forwarded by the organizers upon the 
receipt of your deposit. The prepaid rate will be deducted from your hotel bill upon presentation. 

Please, return this form before Sept. 30. The following prices (in it. lire) are per room and per night and they include taxes and continental breakfast. 
4 STARS: Single room 200.000/250.000 - Double room 270.000/300.000.3 STARS: Single room 120.000/150.000 - Double room 160.000/190.000. 
Social event 

The organization booked some seats at the ALLA SCALA theatre for Carreras' concert on the evening of October 23rd. Prices will be around 
120.000/180.000 it. lire. If you are interested, please make sure to reserve your seat by marking the SOCIAL EVENT option in the form. 


This form with the cheque (or copy of the bank transfer or payment order) should be sent to: 

ESEC 91 Organizing secretariat :Via Donizetti 36 20122 Milano -Italy. To avoid delays, please fax the form and the copy of the payment to: 
ESEC 91 Organizing secretariat + 39-2-76009751. For more information, please call ESEC 91 Organizing secretariat + 39-2-76001633 


REGISTRATION FORM 


ESEC 91 - European Software Engineering Conference 


HOTEL BOOKING FORM 


Surname_ 

First name _ 


Company/University _ 

Address_ 

City_ 

Country_ 


Accomodation required: 

□ 4 STARS □ SINGLE ROOM 

□ 3 STARS J DOUBLE ROOM 

Date of arrival_ Date of departure_ 

For a total of_ nights 


Conference registration fee (before Sept.30) 


□ REGULAR 750.000 it. lire 

□ MEMBER* 650.000 it. lire 

□ STUDENT 550.000 it. lire 

□ ORGANIZATION 0 300.000 it. lire 

Late registration (after Sept, 30) add 100.000 it. lire. 


Tutorial registration fee 

□ REGULAR 

□ MEMBER* 

□ STUDENT 

□ ORGANIZATION 0 

Tutorial number: 1 □ 2 0 

* ATI, AICA, BCS, GI, SI, AFCET, ACM, IEEE » Cc 


350.000 it. lire 
300.000 it. lire 
200.000 it. lire 
150.000 it. lire 


30 4 O 

n. Members, Sess. Chairmen and Panelists 


Payment: 

O Bank cheque O Bank wire transfer 

O Card Nr. 

H 

Expiration date ii n il 

Signature 

m 



SOCIAL EVENT - Oct. 23rd 


O Please, reserve_ticket(s) for me for the concert at 

the ALLA SCALA theatre. 




























ESEC 91 ADVANCE PROGRAMME 

MONDAY, 21 OCTOBER 1991 


TUTORIALS 

09.30-12.30 
14.00-17.00 

OBJECT MANAGEMENT FOR 
SOFTWARE ENVIRONMENTS 

J. C. Wileden, Univ. of Massachussets 
at Amherst, USA 

A. L. Wolf, AT&T Bell Labs, USA 

DISTRIBUTED REAL-TIME 

FAULT-TOLERANT 

COMPUTING 

Gdrard Le Lann, INRIA, France 

DESIGN METHODS 

J. Ebert, Universitat Koblenz-Landau, 
Germany 

G. Engels, Technische Universitat 
Braunschweig, Germany 

OBJECT-ORIENTED 
SOFTWARE DEVELOPMENT 

B. Meyer, Interactive Software 
Engineering Inc, USA 

TUESDAY, 22 OCTOBER 1991 

09.30-10.00 

Opening Address 

Program Chair: A. van Lamsweerde, University Catholique de Louvain, Belgium 

10.00-11.00 

Keynote Address: 

SOFTWARE CONFIGURATION MANAGEMENT: PAST USES AND FUTURE CHALLENGES 

S. Feldman, Bellcore, USA 

11.30-12.30 

Invited Talk: 

ARCHITECTURAL DESIGN OF USER INTERFACES 

J. Coutaz, University of Grenoble, France - Chair: C. Potts, MCC, USA 

parallel 

sessions 

14.00-15.00 

ENVIRONMENTS 1 - Chair: W, Tichy, Universitat Karlsruhe, Germany 

Scaling Up Rule-Based Development Environments 

N.S. Barghouti and G.E.Kaiser, Columbia University, USA 

Inference-Based Support for Programming in the Large 

G. Snelting, F.J. Grosch and U, Schroeder, T.H. Darmstadt, Germany 

FORMAL APPROACHES - Chair: P. Lohr, Freie Univ. Berlin, Germany 
Integrating Structured and Formal Methods: A Visual Approach to VDM 

J. Dick and J. Loubersac, BULL, France 

Rational Design of Distributed Applications 

T. Cattel, DEC and University de Franche-Comty, France 

parallel 

sessions 

15.00-16.00 

REAL-TIME SYSTEMS 1 - Chair: H. Horgen, VERILOG, France 

ASTRAL: An Assertion Language for Specifying Real-Time Systems 

C. Ghezzi, Politecnico di Miilano, Italy, and R.A. Kemmerer, UCSB, USA 

Execution Environment for ELECTRE Applications 

D. Creusot, P. Lemoine, 0. Roux, Y, Trinquet. LAN-ENSM, and A. Kung, 0. 

Marbach, C. Serrano-Morales, TRIALOG, France 

FORMAL BASES - Chair: J. Finance, CRIN, France 

Algebraic Validation of Software Metrics 

M. Shepperd, Bournemouth Polytechnic, and D. Ince, Open University, UK 

An Algebraic View of Inheritance and Subtyping in Object-Oriented 
Programming 

F. Parisi Presicce and A. Pierantonio, Univ. de L'Aquila, Italy 

16.30-18.00 

IMPACT OF SOFTWARE ENGINEERING RESEARCH ON INDUSTRIAL PRACTICE - Organiser: A. Fuggetta, CEFRIEL, Italy 

Participants: R. Troy (Verilog, France), C, Jackson (British Telecom, UK), M.C. Gaudel (University de Paris-Sud, France), V. Frasca (Tecsiel, Italy) 

WEDNESDAY, 23 OCTOBER 1991 

09.00-10.00 

Invited Talk: COMPUTER SECURITY AND SOFTWARE ENGINEERING 

R. A. Kemmerer, University of California at Santa Barbara, USA - Chair: C. Ghezzi, Politecnico di Milano, Italy 

10.00-11.00 

Invited Talk: SYNCHRONOUS PROGRAMMING FOR REAL-TIME AND REACTIVE SYSTEMS 

G. Berry, Ecole Nationale Supdrieure des Mines, France - Chair: D, Mandrioli, Politecnico di Milano, Italy 

parallel 

sessions 

11.30-12.30 

REAL-TIME SYSTEMS II - Chair: S. Greenspan, GTE Laboratories, USA 

An Engineering Approach towards Hard Real-Time System Design 

H. Kopetz, R. Zainlinger, G, Fohler, H. Kantz, P. Puschner, W. Schutz, Technische 
Universitat Wien, Austria 

An Application of Al to Prototyping Process for Performance Design in Real- 
Time Systems 

S. Honiden and N. Uchihira, TOSHIBA, and K. Itoh, SophiaUnivesity, Japan 

SOFTWARE RE-ENGINEERING ■ Chair: R. Mittermeir, Universitat 
Klagenfurt, Austria 

A Theory for Software Design Extraction 

B.A. Sijtsma and J.W. Mager, Shell Research, The Netherlands 

Improving Software Reusability by Program Specialization: A Case Study 

A. Coen-Porisini and F. De Paoli, Politecnico di Milano, Italy 

parallel 

sessions 

14.00-15.30 

ENVIRONMENT II- Chair: Peter Hruschka, GEI, Germany 

TICKLE: Object-Oriented Description and Composition Services for Software 
Engineering Environments - T. Collins, K. Ewert, C. Gerety, J, Gustafson and 1. 
Thomas, Hewlett-Packard, USA 

Integrated Project Support Environments, Text Generation and Technical 
Writing - C. Tattersall, Leeds University, UK 

The ARCS Experience - D. Schefstrom, TELESOFT, Sweden 

METRICS - Chair: A. Endres, IBM, Germany 

Metric-Driven Classification Analysis 

R.W. Selby and R.K. Madsen, University of California at Irvine, USA 

A Dynamic Failure Model For Estimating the Impact that a Program 

Location Has on the Program - J Voas, NASA, USA 

Relation Between Source Code Metrics and Structure Analysis Metrics 

1. Rozman, J. Gyorkos and T. Dogsa, University of Maribor, Yugoslavia 

parallel 

sessions 

16.00-17.30 

REQUIREMENTS ENGINEERING: THE NEATS VERSUS THE 
SCRUFFIES 

Organiser: S. Fickas, University of Oregon, USA 

Participants: M. Feather (Information Science Institute, USA), A. Finkelstein 
(Imperial College, UK), S. Greenspan (GTE Laboratories, USA), W. Scacchi 
(University of Southern California, USA) 

CASE SUPPORT FOR THE SOFTWARE PROCESS 

Organiser: P. Hruschka, GEI, Germany 

Participants: panelists still to be confirmed 

THURSDAY, 24 OCTOBER 1991 

parallel 

sessions 

09.00-10.00 

EXPERIENCE WITH FORMAL METHODS - Chair: R. Jacquart, CERT, 

Test Data Selection From the Algebraic Specification of a Module of an 
Automatic Subway 

P. Dauchy and B. Marre, University de Paris-Sud, France 

Specification in COLD-1 of a CAD-Package For Drawing Shadow Masks 

F.J. van der Linden, Philips, The Netherlands 

COPING WITH CHANGES - Chair: J. Winkler, Siemens, Germany 
Dynamically Replaceable Software: A Design Method 

J. Amador, Grupo de Mecanica del Vuelo, B. de Vicente, TEICE Control, and 

A. Alonso, Universidad Politycnica Madrid, Spain 

Software Merge: Models and Methods for Combining Changes to Programs 

V. Berzins, Naval Postgraduate School, USA 

10.30-11.30 

Invited Talk: FROM SOFTWARE RESEARCH TO PRODUCTION USE: A TRANSFORMING EXPERIENCE 

R. Jullig, Kestrel Institute, USA - Chair: V. Donzeau-Gouge, CNAM and INRIA, France 

11.30-12.30 

Invited Talk: PERSPECTIVES ON THE EUREKA SOFTWARE FACTORY 

C. Fernstrom, Cap Gemini, France - Chair: A. Fuggetta, CEFRIEL, Italy 

































PRODUCT REVIEWS 


Issue Editor: Sorel Reisman, California State University, Fullerton. 
Send review submissions to Richard Eckhouse, MOCO Inc., 776A Country Way, N. Scituate, MA 02066; Compmail r. eckhouse; Internet, eckhouse@cs.umb.edu. 


The availability of computer- 
aided software engineering 
(CASE) tools for personal com¬ 
puters is a relatively recent phe¬ 
nomenon. Nevertheless, the in¬ 
creasing power of PCs and the 


MicroSTEP Version 1.5 

Richard. G. Estock, EDP Consultants 

MicroSTEP is a graphical CASE 
tool used to generate PC-based rela¬ 
tional database applications. (STEP 
stands for specification to executable 
program.) This package from Syscorp 
International generates .EXE files 
and produces single-user stand-alone 
or multiuser network-based programs. 

MicroSTEP expresses specifications 
for programs or applications in dia¬ 
grams, and the user manipulates win¬ 
dow icons to represent dataflow. The 
user completes the specification by 
systematically selecting icons and stip¬ 
ulating the data structure for databas¬ 
es, the formats for screens or reports, 
and the activities to be performed in 
specified processes. 

The graphical interface for all these 
actions is very similar to what you 
would expect on a Macintosh platform 
or Sun workstation. The diagramming 
symbols and icons draw heavily upon 
an entity-relationship style, although 
MicroSTEP does not necessarily ad¬ 
here to an E-R approach. 

A specification can be checked at 
any time for completeness. When the 
specification is perfected, the user ini¬ 
tiates a BuildApp command that caus¬ 
es source code to be generated, com¬ 
piled, and linked. The application can 
then run on the host machine or be 
ported to another PC. 

MicroSTEP comes with Microsoft’s 
5.1 C compiler and Novell’s Btrieve/N 
record management system and key- 
indexed file handler. Although imple¬ 
mentations can be accessed indepen¬ 
dently, no separate documentation is 
provided for them. 


CASE tools 

growing popularity of graphical user 
interfaces let tool developers offer a 
broad range of products for IBM PC 
and Apple Macintosh platforms. The 
following tool reviews reflect the di¬ 
verse spectrum of available price 


Inc. 

MicroSTEP is now in its third year 
and fifth release. Version 1.5 adds 

• Novell NetWare compatibility, 
with locks to tables and records 
for multiuser applications; 

• better techniques for maintaining 
data integrity and concurrency; 

• a commit/rollback feature to pro¬ 
tect the database upon abnormal 
termination; and 

• continued improvements in per¬ 
formance and utilization. 

Generated applications can also run 
on diskless workstations. 

Installation. The package comes on 
eight 1.2-Mbyte, 5.25-inch disks or 11 
720-Kbyte, 3.5-inch disks. An addi¬ 
tional disk is provided for Building 
Blocks, a collection of notes and prac¬ 
tical procedures that expedite recur¬ 
ring tasks in the application-develop¬ 
ment process. 

The installation process went 
smoothly, taking about 15 minutes. 
Approximately 8 Mbytes of free disk 
space are required for the resident 
system files, and each application 
takes 1 to 2 Mbytes of additional disk 
space. Another 1 to 2 Mbytes of disk 
space are required for intermediate 
working files to check, generate, com¬ 
pile, and link data. 

Other system requirements are an 
IBM-compatible PC with 640 Kbytes 
of memory and a Microsoft-compati¬ 
ble mouse; a Hercules, EGA, or com¬ 
patible video card; and DOS 3.1 
through 3.3 only. The product retails 
for $7,500 and is not copy protected. 


ranges, platforms, and user interfac¬ 
es. This small sample of selected 
tools indicates that there is some¬ 
thing for everyone who wants to use 
evolving software engineering prac¬ 
tices to develop complex systems. 


(DOS 5.0 was not available at review 
time.) 

Documentation. Three manuals are 
provided: an encyclopedic 650-page 
reference manual for experienced us¬ 
ers, a 350-page tutorial that takes be¬ 
ginners through the development pro¬ 
cess of a significant project, and a 
125-page Building Blocks manual. 
Each is well written, highly readable, 
and professionally typeset. 

The Building Blocks manual is 
missing several chapters that will be 
provided with future releases. Topics 
include how to do date arithmetic, 
summarize totals by category, and se¬ 
lect a record from a displayed group. 

All manuals have extensive tables 
of contents and indexes, and the refer¬ 
ence and tutorial manuals come with a 
useful glossary and include a handy 
quick reference guide. 

The tutorial covers the develop¬ 
ment of a reasonably significant point- 
of-sale system. In a few sections the 
tutorial material did not match the 
MicroSTEP system. Some simple 
workarounds had to be improvised on 
the fly, but there were no major errors 
or serious omissions. 

Training. Gaining maximum benefit 
from this complex product requires 
formal classroom training. The com¬ 
pany offers a three-day exploratory 
class (included in the price of the 
product) in several major cities. Each 
purchaser may send two representa¬ 
tives to the class, which is for new us¬ 
ers who have completed the tutorial 
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Figure 1. MicroSTEP screen arrangement. 


and have gained some facility with the 
package. 

The hands-on class typically pro¬ 
vides a PC for each participant. In the 
class I took, various types of partially 
developed applications demonstrated 
MicroSTEP features. Many useful 
techniques and methods were taught, 
and some undocumented features 
were covered. The company also of¬ 
fers experienced developers a two-day 
advanced concepts class and a one- 
day networking applications class 
(both cost extra). 

Customer support. Customer sup¬ 
port is excellent. A toll-free number is 
available for unlimited calls for the 
first year. During that time, new re¬ 
leases are automatically sent to all 
registered users at no additional cost. 
Afterward, a $900 extended support 
package includes free updates. 

The support-desk staff proved very 
knowledgeable about the few queries 
I had, and, in one instance where an 
answer was not immediately available, 


they responded within a few hours. 
The company also provides a 24-hour 
bulletin board service for registered 
users to upload and download files, 
leave messages, read current news 
about MicroSTEP, etc. A toll-free call 
accesses the BBS. 

A system tour. Figure 1 shows part 
of the MicroSTEP screen organiza¬ 
tion. Work sessions begin at the top 
level, called TopSTEP. Specifications 
completed or under development are 
shown pictorially in a second screen. 
From this screen, you can select an ex¬ 
isting specification to edit or open a 
new one. Let’s consider an application 
called TOP_MENU. 

From the top screen, you gain entry 
into the Flow Diagram Builder and/or 
the Data Dictionary Editor. The 
graphical depiction of the application 
is created in the Flow Diagram Build¬ 
er. The Data Dictionary Editor allows 
for the modification of entries in the 
Data Dictionary repository. 

Within the Flow Diagram Builder, 


you can design the application pictori¬ 
ally, selecting and linking databases, 
processes, auxiliary input, files, re¬ 
ports, screens, subspecifications, ex¬ 
ternal functions, and other data ob¬ 
jects. Should a diagram exceed the 
size of the screen, MicroSTEP pro¬ 
vides an off-page connector and full 
zoom in/out capabilities. 

The Data Structure Builder speci¬ 
fies the order, attributes, and group¬ 
ing of fields in the relational database 
table. Fields are easily established, 
moved, edited or deleted. The inter¬ 
face and record depiction are graphi¬ 
cal, with dialog boxes appearing to 
query the user about field names and 
other attributes. Groups and repeat¬ 
ing groups within a record are accom¬ 
modated. 

The Data Format Builder lets users 
design and lay out forms for reports 
and/or video screens. There are actu¬ 
ally two subscreens, one for reports 
and one for screens and menus. Mar¬ 
gins and placement of labels, head¬ 
ings, and footers are handled graphi¬ 
cally. A pull-down menu lets you view 
the form as an end user would see it. 

The Activity Builder lets you speci¬ 
fy how input data are matched and 
processed and also sets forth from 
where output data are derived. Differ¬ 
ent subdiagrams are displayed for var¬ 
ious situations. A Notes dialog box 
lets you record descriptions and ra¬ 
tionales for the process at hand, help¬ 
ing to document the specification as a 
whole. 

When you select the inputs, pro¬ 
cesses, and outputs in turn, an Expres¬ 
sion Builder is called to formulate the 
flow control and filter and match con¬ 
ditions that must exist before a task 
can be processed. The Expression 
Builder also has error messages. 

The Flow Control Builder lets you 
set the conditions that must be met 
before the subsequent process can be 
executed. It is the means by which a 
single data path is chosen from among 
several alternatives. Like all the build¬ 
ers, everything is displayed and ma¬ 
nipulated graphically. 

Gross errors are flagged immediate¬ 
ly. More subtle mistakes are uncov¬ 
ered in a manually invoked Check 
Specs option that operates on the dia¬ 
grams and data dictionaries. The 
Check Specs facility is automatically 
called when you invoke the BuildApp 
option. 

Although an on-line help system is 
integral to MicroSTEP, the message 
bar at the top line of every window 
provides such a succinct explanation 
of choices that you probably won’t 
need the help system (I didn’t). 
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Producing documentation. Report¬ 
ing and documentation capabilities 
greatly enhance the value of any pro¬ 
ductivity tool. MicroSTEP lets you 
print the dataflow diagram, the data 
dictionary and structures, the defined 
formats for reports, screens and 
menus, and all activities with associat¬ 
ed conditions. The resulting output, 
which includes notes recorded in the 
Activity Builder, constitutes as com¬ 
plete a record as you could want. The 
only missing piece is a user-supplied 
narrative to describe the intended ap¬ 
plication. 

Developing an application. It is not 

necessary to diagram a complete ap¬ 
plication before invoking MicroSTEP. 
You typically start with a simple activ¬ 
ity central to the application and ex¬ 


press this activity in MicroSTEP’s 
graphical language. 

The point-of-sale application in the 
tutorial manual features a new specifi¬ 
cation called ENTER_SALE that has 
two input links, a CUSTOMER data¬ 
base, and an INVENTORY database. 
This diagram appears only in the Flow 
Diagram Builder window. 

The input links connect to the pro¬ 
cess portion of the activity. After de¬ 
fining the database table structure for 
both CUSTOMER and INVENTO¬ 
RY, you define the data structure for 
the ENTER_SALE activity. 

The upper part of Figure 2 shows 
the data structure in the active win¬ 
dow. Since most of the fields already 
exist in the CUSTOMER and IN¬ 
VENTORY databases, MicroSTEP 
allows you to conveniently copy a 


field or group from the reference win¬ 
dow (lower part of Figure 2) into the 
active window. New fields unique to 
the data structure shown in the active 
window are readily added, and exist¬ 
ing fields can be modified or moved. 

MicroSTEP has an autosave feature 
that can be specified by a variable in 
your system environment. Every few 
minutes, autosave takes a snapshot of 
the system. You can manually invoke 
the autosave feature by hitting Alt-S. 

Additional processes that are de¬ 
fined as part of this application are 
the printing of an invoice for a charge 
customer or a receipt for a cash cus¬ 
tomer. You do not need to design a 
form because MicroSTEP provides a 
default format. 

Although most MicroSTEP window 
interactions are fairly quick, clean, 
and robust, the Report Builder func¬ 
tions are cumbersome. The tedious 
placement of fields and labels fre¬ 
quently results in an overlap condition 
in which the white spaces of two fields 
coincide — but are not visible. Later, 
when you try to leave the Report 
Builder, the error is flagged, leaving 
you puzzled about the location of the 
problem. Moreover, you have to re¬ 
solve this problem before any further 
action can be taken, including saving 
the work in progress. 

Figure 3 shows the completed flow 
diagram for a point-of-sale applica¬ 
tion. Note the circled question marks 
on the links for PRINTJNVOICE 
and PRINTJIECEIPT. These flag 
the links as ones exhibiting flow con¬ 
trol. In this example, the path that 
would be taken is dependent upon the 
method of payment. (The path and 
the method are mutually exclusive.) 
These conditions were expressed in 
the Activity Builder. 

Figure 3 also shows an 
UPDATE_INV process, linked to two 
duplicate INVENTORY databases. 
Note the directions of the links. In 
this case, items purchased are used to 
adjust the quantities on hand in the 
INVENTORY database. 

Figure 3 also shows two other pro¬ 
cesses. UPDATE JOURNAL main¬ 
tains a running record of transactions, 
recording pertinent information in a 
serial file. ADDJTRANS is similar to 
the UPDATE JOURNAL task. In 
this instance, a record of all charge 
transactions is kept in a database 
named TRANSACT. Note the flow- 
control symbol on the link between 
the ENTER_SALE output and the 
ADD_TRANS process. 

The Data Flow Diagram in Figure 3 
gives the overall dataflow of the appli¬ 
cation. To see the nuances of the data 
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involved, control criteria, etc., you se¬ 
lect the object in question and migrate 
it to the appropriate screen where all 
pertinent information is displayed. 

To get to Figure 3, you must take a 
modular, top-down design approach. 
Using the Flow Diagram Builder, you 
can add, delete, or modify objects as 
the application takes form. A given 
specification can constitute a module 
that can call other modules or be 
called as a module. 

A specification need not be com¬ 
plete to do other work. In the Mi- 
croSTEP tutorial, after SALES is fully 
developed, the additional specifica¬ 
tions or modules named INQUIRY 
and TOP_MENU are created. These 
reference SALES as a subspecifica¬ 
tion. The INQUIRY specification per¬ 
forms customer lookups utilizing the 
CUSTOMER and TRANSACT data¬ 
bases. TOP_MENU lets you invoke 
INQUIRY or SALES. 

When specifications are complete, 
invoking the BuildApp command au¬ 
tomatically calls Check Specs, Gener¬ 
ate Code, and Compile Code from the 
program pull-down menu. The Build- 
App process for the sample point-of- 
sale application took about 8 minutes 
to complete on a 6-MHz IBM PC AT. 

My older AT machine generally 
proved to be fast enough for the Mi- 
croSTEP program. If you are using an 
even older XT, the company recom¬ 


Macintosh CASE tools 

Giovanni Perrone, GP Systems 

The Macintosh has been the “sleep¬ 
er” of computing platforms for low- 
cost CASE tools from its introduction. 
It provides a very cost- effective solu¬ 
tion for automating many system de¬ 
velopment and software engineering 
tasks. Among its strengths are an 
easy-to-use graphics-oriented inter¬ 
face, easy-to-produce “print shop” 
quality graphics output, and easy-to- 
obtain connectivity among systems. 
The highly appealing Mac environ¬ 
ment was quickly recognized by many 
system developers even before the 
current selection of software tools was 
available. Recently, however, CASE 
products for the Macintosh family 
continue to grow as CASE vendors 
recognize the advantages of Mac- 
based tools. 

Excel Software was one of the first 
to support structured analysis on the 
Mac when it introduced MacAnalyst. 
Shortly afterwards, it introduced Mac- 
Designer for structured design. The 


mends a 286 accelerator card. Mi- 
croSTEP supports a 720 x 348 resolu¬ 
tion with a Hercules video adapter, or 
both 640 x 350 and 640 x 200 resolu¬ 
tions with an EGA board. My review 
was conducted in 640 x 350 EGA 
mode. With all the text and graphical 
information that MicroSTEP presents, 
I found that resolution to be just bare¬ 
ly adequate. VGA resolution is clearly 
called for, but a company representa¬ 
tive told me it has no immediate plans 
to offer VGA because of technical 
reasons. With 800 x 600 Super VGA 
and 1,024 x 768 8514/A noninterlaced 
resolutions becoming commonplace, 
MicroSTEP might be losing some 
ground. 

While MicroSTEP itself is confined 
to running under DOS 3.1 through 3.3, 
the generated applications can run on 
any DOS 3.1 or above. 

Rapid prototyping. The most attrac¬ 
tive use of MicroSTEP is as a rapid ap¬ 
plication prototyper. In several hours, 
given a rough sketch of an application, 
you can develop a working program 
that can be readily installed and test¬ 
ed. End users can then identify likes 
and dislikes, with suggestions being 
quickly and efficiently accommodated. 
Thus, MicroSTEP lends itself to an in¬ 
cremental development effort that can 
interactively involve end users. This 
process is very beneficial to these us¬ 


initial versions of both products were 
well-received, capable tools, but the 
latest versions — MacAnalyst/Expert 
3.0 ($1,595) and MacDesigner 3.1 
($795) — are simply formidable. 

When used together, they constitute a 
flexible, integrated, and highly sophis¬ 
ticated “upper” CASE tool combo 
that is surprisingly easy to use and af¬ 
fordable. 

Both MacAnalyst/Expert and Mac- 
Designer run on any Mac with at least 
2 Mbytes of memory. They also sup¬ 
port LaserWriter or ImageWriter 
printing, large-screen/monitors, and 
network options on the Mac System 
6.0 or later or Aux 2.0. 

MacAnalyst/Expert features. This 
bundled software is the first of two 
key players in the upper CASE tool 
family. Other lower cost versions of 
MacAnalyst are also available. The 
MacAnalyst/Expert tool automates a 
wide variety of analysis tasks in the 


ers because they can see what the ap¬ 
plication delivers as it takes form. An 
application as complex as the point-of- 
sale program could be completed by 
an experienced MicroSTEP developer 
in under three hours. By contrast, an 
identical effort using one of Micro- 
STEP’s closest competitors (like Clip¬ 
per) would take an equally adept de¬ 
veloper about 12 hours. 

Recommendations. MicroSTEP is 
an industrial-strength database appli¬ 
cation generator that, at $7,500, is 
clearly beyond the reach of a work-at- 
home enthusiast. It fits nicely into an 
environment in which many applica¬ 
tions are under development. It also 
supports minimal development time, 
frequent modifications to existing ap¬ 
plications, and commonality of stan¬ 
dards and documentation among many 
applications. 

As a rapid prototyping tool, it is es¬ 
pecially desirable for building demon¬ 
strable systems from which better user 
requirements can be determined be¬ 
fore any sizeable investment in time or 
money occurs. 

Readers may contact Syscorp Inter¬ 
national Echelon IV at 9430 Research 
Blvd., Ste. 300, Austin, TX 78759; 

(512) 338-5800; (800) 727-7837; fax 
(512) 338-5810. 
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system-development life cycle. One of 
its major strengths is flexibility. It can 
be applied very rigorously in a specific 
analysis methodology such as Your- 
don/DeMarco structured analysis or 
used very loosely in support of an 
emerging analysis technique such as 
object-oriented analysis (OOA). 

MacAnalyst/Expert supports most 
current analysis methodologies and 
techniques through a structure based 
upon a series of “documents.” For 
analysis tasks, the MacAnalyst/Expert 
documents are categorized as follows: 

• Analysis documents for dataflow 
diagrams (DFDs) and control-flow 
diagrams used in traditional and 
real-time structured analysis. 

• Data model documents for entity- 
relationship) diagrams used in 
structured analysis, data modeling, 
information modeling, and OOA. 

• State model documents for state 
transition diagrams, process acti- 


August 1991 


99 





vation tables, decision tables, state 
transition matrices, and state tran¬ 
sition tables for real-time struc¬ 
tured analysis. 

► Requirement documents that con¬ 
tain a requirements database to 
identify, specify, and track re¬ 
quirements during system devel¬ 
opment. These can be used with 
any methodology needing require¬ 
ments traceability, verification, 
and validation. This is especially 
useful for systems developed un¬ 
der the US Department of De¬ 
fense system development stan¬ 
dard DoD-Std-2167A. 

’ Data Dictionary documents that 
serve as a repository for catalog¬ 
ing all the data definitions and re¬ 
lationships in a system. The Data 
Dictionary binds all other system 
documents and is used with all 
analysis methodologies and tech¬ 
niques. 

■Text documents with standard text 
editing windows and double-click 
access from DFD processes to tex¬ 
tual process descriptions. These 
are used as the elements of system 
(mini)specifications. 


CASE review note 

Visible Analyst Workbench. 

This CASE Tool from Visible Sys¬ 
tems is a set of smoothly linked in¬ 
tegrated modules that consists of 

(1) the Process Model to specify 
what the system should do, 

(2) the Design Model to de¬ 
scribe how to implement the 
system, and 

(3) the optional Data Model to 
establish the interrelation¬ 
ships among different data 
elements. 

A database manager (or Reposito¬ 
ry) resides behind these tools and 
drives the optional Prototyper. 

A mouse is required for internal 
navigation. 

To use the system, you must first 
draw dataflow diagrams (Yourdon 
and Gane/Sarson methods are in¬ 
cluded) for the process model to 
specify what the system is to do. 
Entries are automatically generat¬ 
ed when you label a line or draw a 
symbol. You can also interactively 
create and edit entries. Child en¬ 
tries are generated by the system 
when you fill in a Parent’s compo¬ 


This structure is simple yet elegant. 
You open the documents necessary to 
model a system, based on the method¬ 
ology being applied. The comprehen¬ 
sive modeling tools within each docu¬ 
ment window provide the mechanisms 
to choose a desired methodology. For 
example, the Analysis window allows 
the use of Yourdon/DeMarco or Gane 
and Sarson analysis methods. A tool 
palette available in each document 
window further extends the supported 
methods, such as the availability of 
control flow (dashed lines) and con¬ 
trol process (dashed circles) drawing 
tools for real-time extensions to struc¬ 
tured analysis. 

Looking at a few key specifications 
gives another view of MacAnalyst/Ex- 
pert capabilities. The package sup¬ 
ports up to 250 diagrams and 5,000 
objects per document. Diagrams in a 
document can be “leveled” to a depth 
of 25 and have up to 10 horizontal and 
10 vertical pages. A Dictionary or Re¬ 
quirement document can have up to 
32,000 entries with 40 characters per 
entry name and 400 referenced docu¬ 
ments. Text files can contain up to 
32,767 characters per document. 


sition fields with structured En¬ 
glish statements. You then create structure 
charts (Yourdon/Constantine) to de¬ 
tail the design. Finally, you set up da¬ 
tabase views (Chen Entity Relation¬ 
ship, Information Engineering E-R. 
and Bachman E-R diagrams) to de¬ 
fine the data model. The next step is 
to test the integrity of these views by 
applying the rules associated with the 
drawing types. You can then manipu¬ 
late the Repository or Data Dictio¬ 
nary database manager that resides 
behind the drawings. 

You can use previously defined 
data held in the Repository to drive 
the Prototyper. The Prototyper’s 
screens can be linked together in a hi¬ 
erarchy to produce a slide show of 
how the system will perform. 

A key feature of this system is the 
bridges or links between each of the 
modules — the Process Model (speci¬ 
fication), Design Model (design), and 
Data Model (views) — via the Reposi¬ 
tory. Another handy feature is the 
ability to look up or specify a Reposi¬ 
tory data item through a filter by type 
and wild card search. The Visible An¬ 
alyst Workbench is unique in that the 
repository entries for the Design 


MacDesigner features. MacDesigner 
is the second key player in the tool 
family. It automates the system design 
tasks in the development life cycle, 
providing even better flexibility than 
MacAnalyst/Expert. It is preconfig¬ 
ured for the Yourdon/Constantine 
method of structured design, includes 
modeling constructs for the still- 
emerging object-oriented design 
(OOD), and can also be customized 
for variations of design methodolo¬ 
gies. 

MacDesigner modeling tools include 
structure charts, module descriptions, 
inheritance diagrams (used for OOD), 
tree diagrams, and a data dictionary 
and requirements database that are 
both compatible and integratable with 
MacAnalyst/Expert. MacDesigner 
shares its document-support structure 
with MacAnalyst/Expert. The docu¬ 
ments that support design tasks are 

• Design documents for constructing 
structure charts, inheritance dia¬ 
grams, tree diagrams, and cross- 
reference lists used to model the 
organization and relationships of 
software modules; 


Model’s modules and data items 
can be linked to the Requirements 
Model’s processes and data items 
through a “related to” field. 

Repository reports are complete 
and configurable. This means you 
can create a subset, such as: “Print 
all items related to the following 
branch of the logic.” You can use 
your favorite database manager to 
produce custom reports. 

The Visible Analyst Workbench 
runs on IBM and compatibles un¬ 
der DOS. The package works best 
with more than the minimum 640 
Kbytes of RAM that is specified. 
Although it runs with a CGA, 
EGA, or VGA graphics adapter, 
VGA is preferred for drawing-ori¬ 
ented functions. A Novell LAN- 
based version is also available for a 
minimum of three concurrent us¬ 
ers. The software is priced between 
$1,895 and $3,190, depending on 
which modules are purchased. 

Readers may contact Visible Sys¬ 
tems at 950 Winter St., Waltham, 
MA 02154; (617) 890-2273. 

— Bob Podd, Software Results Inc. 
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• Requirement documents (as used 
in MacAnalyst/Expert); 

• Data Dictionary documents (as 
used in MacAnalyst/Expert). 

• Text documents with standard 
text-editing windows and double¬ 
click access from structure charts 
or inheritance diagram modules to 
textual module descriptions used 
in the design specifications. This 
similarity in design structure be¬ 
tween MacAnalyst/Expert and 
MacDesigner provides a high de¬ 
gree of integratability. It also 
helps to simplify the normally dif¬ 
ficult transition from analysis to 
design inherent in most methodol¬ 
ogies — and overlooked in many 
CASE tool implementations. 

Obviously, the two packages oper¬ 
ate in a similar fashion. Once you 
learn how to use one, you know how 
to use the other. As in MacAnalyst/ 
Expert, you open the documents in 
MacDesigner necessary to model a 
system, based on the methodology be¬ 
ing applied. Modeling tools within 
document windows provide the mech¬ 
anisms for a desired methodology. 

The Design window, for example, lets 
you model with a Yourdon/Constan¬ 


Communications for the 


Microphone II. I’m looking for the 
perfect communications program for 
my Mac. Microphone II comes close, 
although it’s rather expensive for my 
needs. 

I have three communications prob¬ 
lems: 

• The computing environment to 
which I connect is a network of 
Unix workstations and file servers. 
These machines have quirks quite 
unlike those of commercial com¬ 
munications services or public ac¬ 
cess bulletin boards. 

• The only editor I willingly use is 
Emacs, a full-screen portable edi¬ 
tor especially suited to program 
development. This intransigence 
results in some problems that are 
special to Unix full-screen editors 
and some special to Emacs. 

• I download Macintosh binary files 
from remote hosts and need fast 
reliable communications. 

Microphone II’s strongest feature is 
its scripting language, which makes it 
easy to navigate complicated login se¬ 
quences automatically. For example, 
to log in to my Unix hosts, I must 


tine structure chart for structured de¬ 
sign or use an inheritance diagram for 
OOD. The Design window tool palette 
provides the tools to construct the 
symbols and text used in the model. If 
you are making a structure chart, for 
example, this includes a Module tool 
to draw the boxes representing pro¬ 
gram modules, a Link tool to connect 
the modules, and Couple tools to show 
both Data and Control couples ex¬ 
changed between modules. 

MacDesigner’s Design window goes 
a step further to include a Symbol 
tool. Symbols are user-defined objects 
that you can add to the tool palette to 
customize a design methodology. Al¬ 
though you can define up to nine sym¬ 
bols, the tool palette displays only one 
at a time. Menus and command key 
equivalents quickly change the current 
(displayed) symbol. 

MacDesigner’s key specifications 
are similar to those of MacAnalyst/Ex¬ 
pert, providing equivalent capabilities. 

Tool transparency. Both packages 
are extremely easy to learn and use. 
Only the application details — models 
analysis and models design — differ. 

The abundant tutorials are effective 
in both packages. I did find one case in 


await, recognize, and respond to near¬ 
ly a dozen different prompts starting 
with several issued by the remote 
comm gear and ending with several to 
deal with Unix, the network, and 
Emacs. I automated this process with 
a modest amount of script writing. The 
program has a “watch me” mode that 
captures your keystrokes and the re¬ 
plies, and builds a script that emulates 
what you did. My experience with this 
process was mixed. It initially resulted 
in dropped characters and some lines 
in the wrong order, but I easily made 
it into a script to solve the problem by 
using the excellent documentation. 

I wish Microphone II supported em¬ 
ulation of a terminal more capable 
than the VT102. That minor variant of 
the ubiquitous VT100 suffices for al¬ 
most everything and excels at almost 
nothing. 

All the important serial protocols 
are supported, including Kermit, 
Xmodem, Ymodem, and Zmodem. 

The last one is so much faster and, in 
the Microphone II implementation, so 
well automated, that I don’t use any¬ 
thing else when it is available. 

As with most Macintosh programs, 


MacDesigner where a payroll module 
description (PAYROLL.MD) in the 
Payroll Examples folder wouldn’t 
load, hanging up the system. One fea¬ 
ture, the Capture Requirement com¬ 
mand, wouldn’t work during either 
product’s tutorial — or during further 
testing. Everything else worked as 
claimed. 

You quickly become comfortable at 
the controls of either tool. For CASE, 
there is no substitute for an easy-to- 
use, flexible tool. Most users have 
enough trouble worrying about the 
methodologies. Ideally, you want al- 
most-transparent tool use. MacAna¬ 
lyst/Expert and MacDesigner can do 
this as well or better than any product 
I have used. 

Both products are excellent CASE 
tools easy enough for a novice, yet so¬ 
phisticated enough for a professional. 
In fact, I think they are so cost effec¬ 
tive when compared to some PC- 
based CASE tools that prospective 
CASE purchasers could easily justify 
adding a few Macs. 

Readers may contact Excel Soft¬ 
ware at PO Box 1414, Marshalltown, 
IA 50158; (515) 752-5359. 

Reader Service 23 


it is not overly difficult for Micro¬ 
phone II to put the computer into a 
state that requires rebooting. For ex¬ 
ample, one script I wrote didn’t deal 
adequately with a busy signal and was 
completely uninterruptible. This is en¬ 
demic to both Macintosh and PC pro¬ 
grams, which run under operating sys¬ 
tems whose notions of process control 
were obsolete in 1980.1 found this 
commercial program less often a vic¬ 
tim of these “wedged” states than 
most free programs. I can only hope 
— as more modern operating systems 
emerge for the Macintosh — that pro¬ 
grammers will write programs that 
cannot seize the machine. 

The $295 package price includes 
subscription discounts for several 
commercial information services. Mail 
order prices are around $230. A ver¬ 
sion is also available for IBM PC com¬ 
patibles running Windows. 

Readers may contact Software Ven¬ 
tures Corp. at 3086 Clarement Ave., 
Berkeley, CA 94705-9959; (415) 644- 
3232. — Robert Morris, University of 
Massachusetts-Boston 
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Everything you wanted to know about your PC . . . and more. 


Ed Gordon, Data Systems Associates 


A fully featured, bundled PC can 
be a handful. The typical PC has 
several add-on boards and TSRs 
and runs one of several versions of 
DOS and BIOS. Because of the 
complexity of the typical installa¬ 
tion, fault determination is not al¬ 
ways clear cut. The user must de¬ 
termine the exact configuration of 
any given system and run diagnos¬ 
tics to find the actual fault. 

When a system is not function¬ 
ing correctly, the problem is within 
the software, firmware, or hard¬ 
ware. If a new piece of hardware 
or software cannot be integrated 
into a system, you must locate the 
incompatibility. When a company 
has a mind-numbing collection of 
PCs, system inventory is essential. 
For these reasons and others, com¬ 
panies have decided to manufac¬ 
ture products to diagnose equip¬ 
ment. Three of the products on the 
market are ASQ from Qualitas, 
Info Spotter from Merrill and Bry¬ 
an Enterprises, and System Sleuth 
from the Dariana Technology 
Group. 

All three describe your hard¬ 
ware configuration. The number of 
disks, diskettes, and devices are 
identified by the standard DOS 
scheme. These packages also tell 
you what device drivers are loaded 
and the interrupts to which they 
are attached. They also interrogate 
the system CMOS and BIOS ROM 
and display pertinent information. 
The loaded device drivers and 
TSRs are also displayed. This in¬ 
formation is found in the interrupt 
vectors and the memory map for 
the system. 

These lists are not always all in¬ 
clusive. When two or more TSRs 
steal the same interrupt vector, 
only the last one loaded is dis¬ 
played. You have to look at the 
memory map — and perhaps at the 
object code — to decide whether 
multiple TSRs are handling any 
given interrupt. To simplify this ef¬ 
fort, the company should add a dis¬ 
assembler. 

Also, none of the utilities ana¬ 
lyzed my hard disks correctly. I 
have two disks, one partitioned 
and one not. Each package man¬ 


aged to find somewhere between two 
and three disks, and somewhere be¬ 
tween two and three partitions. This 
was not consistent, even within the 
same package. However, this can be 
considered a minor flaw in three very 
good packages. They are all compre¬ 
hensive and provide valuable informa¬ 
tion. 

There is a big gap in price between 
the three packages. ASQ is very inex¬ 
pensive but provides only passive 
analysis. The other two are around 
$100 but provide passive and active 
analyses and allow you to perform 
various technical functions on your 
system. 

ASQ memory-management tutorial 

and system analyzer. ASQ is a very 
impressive little system analyzer avail¬ 
able essentially as shareware. The 
program is available on bulletin 
boards, most notably, CompuServe. If 
you do not have access to a bulletin 
board, or would rather have a copy 
sent to you by the company, you may 
request a disk for $5. 

This package is purely passive. This 
is not the reason for the price differ¬ 
ential. A clear market value for Quali¬ 
tas exists. The impressive menu sys¬ 
tem is definitely the most user 
friendly of the three. The functions 
are called out on the left of the 
screen, while the explanation of the 
function is called out on the right. 

You can browse and interrogate the 
system configuration by navigating 
through the menus. The information 
is comprehensive and pleasing to the 
eye. 

ASQ is available on CompuServe 
by typing “GO PCVENA” and select¬ 
ing Data Library 8. If you would pre¬ 
fer a disk, the program is available 
from Qualitas at 7101 Wisconsin Ave., 
Ste. 1386, Bethesda, MD 20814; (301) 
907-7438. 
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Info Spotter. Info Spotter has the 
same comprehensive system analysis 
that the other packages have, in addi¬ 
tion to some special active functions. 

You can read and alter your CON¬ 
FIG.SYS and AUTOEXEC.BAT 
files, and the package will make opti¬ 


mization suggestions. It performs 
detailed analysis on the disks them¬ 
selves, returning information on 
disk usage and problems. There is 
also a mechanism for installing 
your utilities into the package. 

You can also use pull-down 
menus to navigate the system. The 
information screens are large, well 
organized, and easy to read. If any 
input is necessary, the user is ade¬ 
quately prompted. The package al¬ 
lows mouse usage. 

Info Spotter costs $79.95 and is 
available from Merrill and Bryan 
Enterprises Inc., 9770 Carroll Cen¬ 
ter Rd., Ste. C, San Diego, CA 
92126; (619) 689-8821. 
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System Sleuth. This package is 
the most comprehensive and ex¬ 
pensive of the three at $149. Sys¬ 
tem Sleuth lets you explore every 
detail of your PC accompanied by 
a dizzying array of colors. You can 
also perform many technical func¬ 
tions on your system. However, 
you should be careful to ensure 
that you don’t destroy the system 
while analyzing it. 

In addition to the passive analy¬ 
sis routines, a comprehensive set of 
active routines perform more de¬ 
tailed analysis. The video tests are 
similar to those available on the di¬ 
agnostics delivered with some com¬ 
puter systems and are pleasant to 
watch. The extensive memory tests 
must be run under careful circum¬ 
stances because they might conflict 
with your current configuration. 

The disk and diskette active 
analysis routines thoroughly diag¬ 
nose the heads and the media. 

Since some tests are destructive, 
you should take care or a disk par¬ 
tition might be reformatted before 
you have a chance to escape. (You 
can reformat your disks if you want 
to.) 

System Sleuth Pro is available 
from the Dariana Technology 
Group Inc., 6945 Hermosa Cir., 
Buena Park, CA 90620; (714) 994- 
7400. 
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THE COMPUTER PROFESSIONALS’ BOOK SOCIETY 





How the Club Works 


YOUR BENEFITS: You get 4 books for $2.95 plus shipping and handling when you join. 
You keep on saving with discounts of up to 50% off as a member. 

YOUR PROFESSIONAL BOOKSTORE BY MAIL: Every 3-4 weeks, you will 
receive the Computer Professionals’ Book Society News describing the Main Selection and 
Alternates, as well as bonus offers and special sales, with scores of titles to choose from. 
AUTOMATIC ORDER: If you want the Main Selection, do nothing and it will be sent 
to you automatically. If you prefer another selection, or no selection at all, simply indicate 
your choice on the reply form provided. You will have at least 10 days to decide. As a member, 
you agree to purchase at least 3 books within the next 2 years and may resign at any time 
thereafter. 

BONUS BOOKS: Starting immediately, you will be eligible for our Bonus Book Plan, 
with savings of up to 80% off publishers’ prices. 

IRONCLAD NO-RISK GUARANTEE: If not satisfied with your books, return them 
within 10 days without obligation! 

EXCEPTIONAL QUALITY: All books are quality publishers’ editions especially 
selected by our Editorial Board. (Publishers’ Prices Shown) 


The easy, reliable way to satisfy 
your professional book needs. 


Computer Professionals’ 

Book Society _ 

Blue Ridge Summit, PA 17294-0870 

Please accept my membership in the Computer Professionals' Book Society and send the 4 volumes 
listed below, billing me $2.95. If not satisfied, I may return the books within ten days without obliga¬ 
tion and have my membership cancelled. I agree to purchase at least 3 books at regular Society 
prices during the next 2 years and may resign any time thereafter. A shipping/handling charge and 

FREE BOOK* I 
















































































1C Announcements 


Company, Model, Function Comments R.S. No, 


Analog Devices 
DAC-8412,-8413 

DACs 

Each 70-ns device provides four independent analog outputs sharing a common bus interface 120 
and digital readback. Features reference voltages from+2.5 to+10V and power dissipation 
less than 60 mW for+5V operation and less than 330 mW with +15V supplies. DAC-8412 re¬ 
sets to center scale, and (otherwise identical) D AC-8413 resets to minimum scale. Available 
in 28-pin plastic DIP, Cerdip, PLCC, and LCC packages. Cost: from $34.50. 

Cirrus Logic 
CL-GD6410 

LCD VGA Controller 

Single-chip VGA controller designed for notebook computers provides 64 shades of gray on 121 
monochrome LCD and can drive a 512-color active-matrix LCD. Functions include host-bus 
interface logic (up to 12.5-MHz operation), LCD panel interface buffering, LCD panel pow¬ 
er sequencing logic, RAMD AC, and memory control logic. Packaged in 160-pin quad flat 
pack. Samples available now. Cost: $65. 

Cirrus Logic 
CL-CD1190 

Interface controller 

Intelligent printer/scanner interface controller provides transfer rates of up to 250 Kbytes 122 

per second with 128-byte FIFO, programmable strobe and Acknowledge signal pulse widths, 
six I/O pins, and on-chip timer. Packaged in a 68-pin PLCC. Cost (10,000s): $21.50. 


Int’l CMOS Technology CMOS EPROM 35-, 45-, and 55-ns devices are organized as 32 Kbytes x 8 bits each for use in 123 
27CX256 high-performance microprocessor and DSP systems. Expected to reduce power consump- 


EPROM 

tion, board space, and cost, while increasing system reliability. Cost (1,000s): 27CX256-35, 

$21.60; -45, $16.50; -55, $13.20. 

Opti Inc. 

EISAWB 

Chip set 

EISA chip set configured for 20-, 25-, and 33-MHz systems contains write-back cache con- 124 

trailer and supports 386DX, 486SX, and 486 32-bit microprocessors. Set includes memory 
cache controller, EISA bus controller, integrated system peripherals, and data bus control¬ 
ler. Each device comes in its own 160-pin plastic flat package. Cost (1,000s): $150. 

Sharp Corp. 
LH1511,LH1512 

LCD drivers 

Drivers capable of 3.0 to 5.5 V battery operation reduce power consumption of LCD panels. 125 

Applications include notebook word processors, notebook PCs, and palmtop PCs. LH1511 
has a common driver, an LCD drive voltage of 10 to 20V, and a 100 LCD drive-output capa¬ 
bility; comes in a 114-pin TCP. LH1512 has a segment driver, an LCD drive voltage of 12 to 

20V, an 80 LCD drive-output capability; comes in a 97-pin TCP. 

Siemens 

Sicure 

Processor chip 

Siemens coprocessor unit for rapid encipherment (Sicure), offers encryption rate of 20 Mbits 126 
per second for standardized DES block cryptogram. Built-in self-test mechanism allows test¬ 
ing of chip during operation without threat to cryptographic security. 

Siemens 

SL(X)2016 

Intelligent Display 

Slim-line device is four character, X/Y stackable, with .4-in. LED display and multiline mes- 127 

sages. Plastic package is 0.4-in. high, 0.784-in. wide, with 0.186-in.-high 5x7 dot matrix LED 
characters. Reads English, German, Italian, and Scandinavian languages. Cost (100s): from 
$20.35. 

S3 Inc. 

86C911 

GUI chip 

Single-chip, multiplatform graphical user interface specifically designed to accelerate appli- 128 
cations running under Windows, Presentation Manager, and X-Window. Features pull¬ 
down menus, icon manipulation, windows movement and resizing, hardware cursor opera¬ 
tions, cut/paste, and the use of multiple-font types and sizes. Cost (1,000s): $75. 

Texas Instruments 
TACT82S411 

Single chip 

Chip provides up to 20-MHz performance for either 286 or 386SX systems. Key features in- 129 

elude auto sense circuitry (identifies CPU); separate CPU and bus clocks; configuration for 
wait states, command delays, and memory organization; support for single or double ROM 

BIOS (one BIOS can support both 286 and 386SX modes); and support for up to 32 Mbytes of 

RAM. 

Unitrode Integrated 
Circuits 

UC3173 

Power amplifier IC 

IC for space- and power-limited servo applications such as high-density disk drives in laptop 130 
or notebook PCs. A full-bridge amplifier addresses parts count, power, supply voltage, cir¬ 
cuit protection, and disk drive head parking. Designed for 12V or 5 V operation and rated for 
continuous output at 0.45 amperes. Comes in 24-pin SOIC “DW" package for low-power ap¬ 
plications, and 28-pin QP, or power PLCC package. Cost (1,000s): DW, $3.55; QP, $3.80. 
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Microsystem Announcements 


Agatech 
E A 4120 

EISA system board 


Aview T echnology 
VG1 

TV board 


Control Systems 
Multi Vision multiuser 
graphics controller 


CSPI 

SC-2XL/VME 
Vector processor 


Data Translation 
DT3831.DT3831-G 
Data acquisition boards 


D VP Inc. 

TSP-C25 

Bus boardEighteen 


Eight Labs 
PL2500 

Array processorICS 


Electronics 
Ines-AT, Ines-PS/2 
GPIB Controller cards 


Mitsubishi 
MF355E 
Floppy drive 

Myriad Solutions Ltd. 
Dash!860/50 
Accelerator board 


EISA 486SX 20-MFlz system board based on Phoenix BIOS includes a socket for optional 135 

Weitek 4167 math coprocessor. Carries Landmark VI .14 performance rating of 89 MHz, of¬ 
fers 8 Kbytes of internal cache and 256 Kbytes of maximum external cache. Optional addi¬ 
tional memory and multifunctional boards. 

VGA version of add-on board turns PCs into Aview Desktop TVs. Uses ITT chip set that 136 

provides double scanning with advanced interpolation technology and comb filters to mini¬ 
mize signal noise. Allows reception of 119 channels, VHF, UHF, cable, videodisc, VCR, and 
other RF-modulated NTSC inputs. Keyboard controls television. Sound comes from an ex¬ 
ternal speaker (included). Cost: $395. 

Graphics system uses standard VGA cards, high-resolution graphic controllers, and a 386 or 137 
486 PC. Focuses on X-Window environment running on a Unix operating system. Allows 16 
graphical users from one PC, provides 100-Mbps data transmission, and runs X-Client appli¬ 
cations. Supports SCO Unix, Xenix, and Open Desktop; is ISA/EISA compatible. 

Supercard i860-based vector processor for VMEbus with 160-Mflops performance, 16 138 

Mbytes of memory, and a 40-Mbps VSB interface. Designed for signal-processing applica¬ 
tions such as sonar, radar seismic, simulation, and real-time processing. Combines two i860 
40-MHz chips in master/slave relationship. Daughterboard options. Available 30 days ARO. 

Cost: from $8,500. 

Board is 12-bit, 50 kHz or 250 kHz AT-compatible and includes embedded anti-aliasing fil- 139 

ters and a real-time error prevention circuit. Analog input capabilities include eight DI chan¬ 
nels, unipolar and bipolar input ranges, 12-bit resolution with maximum system accuracy of 
+0.05% FSR at a gain of 1 and +0.07% FSR at a gain of 8. Included free are DT3831 series 
driver, toolkit, and gallery. Cost: 50-kHZ DT3831, $3,695; 250-kHz DT3831-G, $4,395. 

Single-slot IBM PC bus board for developing telecom DSP systems. Based on TI’s 140 

TMS320C25 DSP, board comes with 64 Kwords of zero-wait-state SRAM, 32 Kwords of 
EPROM, telephone interface with codec (TLC3204x), handset interface with codec, and 
2 Kbytes of dual-port SRAM. Cost: $1,895. 

Single-card array processor occupies one 16-bit I/O channel slot in a PC. Includes 256-Kbyte 141 
cache static memory, up to 4 Mbytes of bulk static memory, 256-Kbyte microcode/table 
ROM memory, connectors for the Span32 bus, a host-interface processor, a 24-bit integer 
processor, and a 32- or 40-bit floating-point engine. Cost: $2,495. 

Sixteen-bit controller cards for AT or PS/2 microchannel bus have driver software for DOS, 142 

OS/2, Xenix, Unix V, and Microsoft Windows. Features automatic DMA data transfer, pro¬ 
cessor-optimized drivers, and 47 HP Basic style commands. Supports over 20 languages, han¬ 
dles up to 15 devices, and permits use of AT’s 488.2 routines. Ines-AT has 1 -Mbps and Ines- 
PS/2 has 500-Kbps data transfer rate. Cost varies with software drivers. Cost: DOS drivers, 

$495; OS/2 drivers, $600; AT&T, SCO Unix V, or SCO Xenix 386 drivers, $900. 

Floppy drive for notebook computers features direct-drive spindle motor, connector types 143 

including a 26-line, 26-line FFC, and 34-line pinhead connector. Formatted capacity is 1.44 
Mbytes, and transfer rate is 500 Kbps (2-Mbyte mode). 

Uses i860/XP RISC to provide 50-MHz operation, with peak throughput of 100 single preci- 144 

sion Mflops. Features 16-Kbyte instruction cache, 16-Kbyte data cache, 50-MIPS integer ex¬ 
ecution unit, 100-Mflops floating-point unit, 3D graphics unit, and 8 Mbytes of DRAM. Uses 
a single 16-bit ATbus slot. Provides 160 Mbps data- transfer rate. 


Parsytec 
TPM-EXP 
Industrial board 


Experimental board includes a T222 transputer section that provides 10 MIPS of local pro- 145 

cessing performance, link communication bandwidth of 9 Mbytes per second, system-wide 
synchronization, a real-time clock, and 64 Kbytes of SRAM. Lithium battery backs up time 
and memory content. Cost: $1,280. . 
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CALL FOR PAPERS 


IEEE Micro invites authors to sub- 
mit general-interest and theme-issue 
papers for publication in 1992 issues. 
Themes include European industry, DSPs, 
associative memories and processors, and 
ICs for HDTV. Submit six copies of each 
paper to Editor-in-Chief Dante Del Corso, 
Dipartimento di Elettronica, Politecnico di 
Torino, C.so Duca degli Abruzzi, 24,10129 
Torino, Italy, e-mail delcorso@polito.it; or 
Ashis Khan, Associate EIC, Mips Com¬ 
puter Systems, 950 DeGuigne Dr., Sunny¬ 
vale, CA 94086, phone (408) 524-7171, 
e-mail ashis@mips.com. For author guide¬ 
lines, dial (714) 821-8380. 

rigjjN CBMS 92, IEEE Symp. on Computer- 
v&Z Based Medical Systems: June 14-17, 
1992, Durham, N.C. For submittal form, 
contact Pete Santago, Bowman Gray 
School of Medicine, Winston-Salem, NC, 
phone (919) 748-2703, fax (919) 748-2870. 


J. of Computer Security seeks articles for 
its first quarterly issue in the fall of 1991. 
Publisher: IOS Press. Submit six copies of 
manuscript to Sushil Jajodia, Information 
Systems and Systems Eng. Dept., George 
Mason Univ., 4400 University Dr., Fairfax, 
VA 22030-4444, phone (703) 764-6192, 
e-mail jajodia@gmuvax2.gmu.edu; or Jon¬ 
athan Millen, Mitre Corp., MS K325, Bur¬ 
lington Rd., Bedford, MA 01730, phone 
(617) 271-3580, e-mail jkm@mbunix. 
mitre.org. 

® CASE 92, Fifth Int’l Workshop on 
Computer-Aided Software Eng.: July 
7-10,1992, Montreal. For submittal infor¬ 
mation, contact Gene Forte, fax (503) 245- 
6935, e-mail g.forte@compmail.com; 

Nazim Madhavji, School of Computer Sci¬ 
ence, McGill Univ., fax (514) 398-3883, 
e-mail case@softeng.cs.mcgilI.ca; or John 
Jenkins, City Univ. of London, Business 
Systems Analysis Dept., London, UK, fax 
44 (71) 608-1270. 


1992 Symp. on Compound Semiconductor 
Physics and Devices: Mar. 23-27,1992, 
Somerset, N.J. Sponsor: Int’l Soc. for Opti¬ 
cal Eng. Submit abstract by Aug. 26,1991, 
and manuscript by Apr. 27,1992, to SPIE, 
PO Box 10, Bellingham, WA 98227-0010, 
phone (206) 676-3290, fax (206) 647-1445 
(in North Am.); SPIE, Xantner Strasse 22, 
D-1000 Berlin 15, Germany, phone (49) 
228-219062 (in Europe); or SPIE, c/o OTO 
Research, Takeuchi Bldg., 1-34-12 Taka- 
tanobaba, Shinjuku-ku, Tokyo 160, Japan, 
phone 81 (03) 3208-7821, fax 81 (03) 3200- 
2889 (in the Far East, Australia, and New 
Zealand). 


CAIA 92, Eighth IEEE Conf. on Ar- 
tificial Intelligence for Applications: 

Mar. 2-6,1992, Monterey, Calif. Submit six 


copies of paper by Aug. 30,1991, and cam¬ 
era-ready paper by Dec. 11,1991, to Jan 
Aikins, Aion, 101 University Ave., Palo 
Alto, CA 94301, phone (415) 328-9595, fax 
(415) 328-0624, e-mail aikins@cup.portal. 


INCOM 92, Seventh Symp. on Information 
Control Problems in Manufacturing Tech.: 

May 25-28,1992, Toronto. Cosponsors: 

Int’l Federation of Automatic Control et 
al. Submit initial draft of full paper by 
Aug. 30,1991, and camera-ready version 
by Jan. 31,1992, to Nicole Leger, Nat’l Re¬ 
search Council Canada, Montreal Rd., 
Bldg. M-19, Ottawa, Ont., Canada K1A 
0R6, phone (613) 993-9431, fax (613) 957- 
9828. 


(fft) IEEE Design & Test plans a special 
Nft? issue on mixed analog/digital systems 
in its March 1992 issue. Submit papers (25 
double-spaced pages, including figures) on 
design synthesis (focus on analog), archi¬ 
tectures, trade-offs between analog and 
digital, test issues, CAD tools (such as 
place/route and mixed-mode simulation), 
new tester complexity (such as features 
needed for the tester and related prob¬ 
lems), and quality assurance by Sept. 1, 
1991, to Manuel d’Abreu, GE R&D, 1 Riv¬ 
er Rd., PO Box 8, KW-C308, Schenectady, 
NY 12301, phone (518) 387-7097, fax (518) 
387-5299, e-mail dabreu@crd.ge.com. 


NASA 92, Goddard Conf. on Space Appli¬ 
cations of Artificial Intelligence: May 1992, 
Greenbelt, Md. Submit two copies of ab¬ 
stract by Sept. 1,1991, and camera-ready 
version by Nov. 15,1991, to Jonathan 
Hartley, NASA Goddard Space Flight 
Center, Code 522, Greenbelt, MD 20771, 
phone (301) 286-3150. 

(£3^ 12th IEEE Symp. on Real-Time Sys- 
terns: Dec. 3-6,1991, San Antonio, 
Texas. Sponsor: IEEE Computer Soc. 
Technical Committee on Real-Time Com¬ 
puting. Submit five copies of extended ab¬ 
stract by Sept. 2,1991. to Lui Sha, Soft¬ 
ware Eng. Inst., Carnegie Mellon Univ., 
4500 Fifth Ave., Pittsburgh, PA 15213, 
phone (412) 268-5875, e-mail sha@sei.cmu. 
edu. 


EDAC 92, European Conf. on De- 
sign Automation: Mar. 16-19, 1992, 
Brussels. Cosponsors: EDAC Assoc, et al. 
Submit nine copies of full manuscript by 
Sept. 2,1991, and final version by Dec. 2, 
1991, to Hugo De Man, do CEP Consul¬ 
tants, 26-28 Albany St., Edinburgh EH1 
3QH, UK, phone 44 (31) 557-2478, fax 44 
(31) 557-5749. 

(£j^) ICSE 92,14th Int’l Conf. on Soft¬ 
's*?' ware Eng.: May 11-15,1992, Mel¬ 


bourne, Australia. Cosponsors: IEEE 
Computer Soc. Technical Committee on 
Software Eng. et al. Submit eight copies of 
paper by Sept. 6,1991, and final version by 
Feb. 1,1992, to Lori A. Clarke, Lederle 
Graduate Research Center, Univ. of Mas¬ 
sachusetts, Amherst, MA 01003, phone 
(413) 545-1328, e-mail clarke@cs.umass. 
edu. 


CAAP 92, Colloquium on Trees in Alge¬ 
bra and Programming, and ESOP 92, Eu¬ 
ropean Symp. on Programming: Feb. 24- 
28,1992, Rennes, France. Submit five 
copies of draft paper by Sept. 6,1991, to J.- 
C. Raoult, IRISA, Campus de Beaulieu, F- 
35042 Rennes Cedex, France, e-mail 
raoult@irisa.fr (for CAAP 92); or B. Krieg- 
Brueckner, FB3 Mathematik und Informa- 
tik, Universitaet Bremen, Postfach 330 
440, D-2800 Bremen 33, Germany, phone 
49 (421) 218-3660, fax 49 (421) 218-3054, 
e-mail bkb@informatik.uni-bremen.de (for 
ESOP 92). 

Third Conf. on Applied Natural Language 
Processing: Apr. 1-3,1992, Trento, Italy. 
Sponsor: Assoc, for Computational Lin¬ 
guistics. Submit six copies of full paper and 
16 copies of abstract by Sept. 10,1991, to 
Oliviero Stock, 1RST, 38050 Povo, Trento, 
Italy, phone 39 (461) 814-444, fax 39 (461) 
810-851, e-mail stock@irst.it (in Europe 
and Asia); or Madeleine Bates, BBN Sys¬ 
tems and Technologies, 10 Moulton St., 
Cambridge, MA 02138, phone (617) 873- 
3634, fax (617) 873-3776, e-mail bates@ 
bbn.com (in the Americas and other conti- 


Fuzz IEEE 92, IEEE Int’l Conf. on Fuzzy 
Systems: Mar. 8-12,1992, San Diego, Calif. 
Sponsor: IEEE Neural Network Council. 
Submit eight copies of paper by Sept. 13, 
1991, to Didier Dubois/Henri Prade, IRIT, 
Univ. Paul Sabatier, 118 route de Nar- 
bonne, 31062 Toulouse Cedex, France, 
phone (33) 6155-6331, fax (33) 6155-6239. 


Fifth Int’l Conf. on VLSI Design: 

Jan. 4-7, 1992, Bangalore, India. 
Sponsor: VLSI Soc. of India et al. Submit 
six copies of camera-ready manuscript by 
Sept. 14,1991, to Yashwant K. Malaiya, 
Computer Science Dept., Colorado State 
Univ., Fort Collins, CO 80523, phone (303) 
491-7031, fax (303) 491-2293, e-mail 
malaiya@ravi.cs.colostate.edu; or K.S. 
Raghunathan, Microelectronic and Com¬ 
puter Division, Indian Telephone Indus¬ 
tries, Bangalore, 560016, India, phone 91 
(812) 563-211, fax 91 (812) 572-824. 


( frKl ICCL 92, Int’l Conf. on Computer 
Languages: Apr. 20-23,1992, San 
Francisco. Sponsor: IEEE Computer Soc. 
Technical Committee on Computer Lan- 
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guages. Submit four copies of paper by 
Sept. IS, 1991, and camera-ready version 
by Jan. IS, 1992, to James R. Cordy, Com¬ 
puting and Information Science Dept., 
Queen’s Univ., Kingston, Canada K7L 
3N6, phone (613) 545-6054, e-mail cordy@ 
qucis.queensu.ca. 

Ada-Europe 92: June 1-5,1992, Amster¬ 
dam Beach, The Netherlands. Submit 10 
copies of extended abstract by Sept. 15, 

1991. and camera-ready final by Feb. 1, 

1992, to Jan van Katwijk, TU Delft Faculty 
TWI, PO Box 356, 2600 AJ Delft, The 
Netherlands, e-mail jan@dutiaa.tudelft.nl. 

EWPC 92, European Workshop on Paral¬ 
lel Computing: Mar. 23-24,1992, Barce¬ 
lona, Spain, Sponsor: Commission of Euro¬ 
pean Communities. Submit five copies of 
full paper by Sept. 15,1991. and camera- 
ready version by Jan. 20,1992, to EWPC 
92 Secretariat, c/o W. Joosen, Departe- 
ment Computerwetenschappen, K.U. Leu¬ 
ven, Celestijnenlaan 200 A, B-3001 Hever- 
lee-Leuven, Belgium, phone (32) 1620- 
1015, fax (32) 1620-5308, e-mail ewpc92@ 
cs.kuleuven.ac.be. 

Int’l J. on Eng. AppVcations of Artificial 
Intelligence plans a special mid-1992 issue 
on intelligent process control. Submit four 
copies of manuscript by Sept. 15,1991, to 
Ming Rao, Chemical Eng. Dept., Univ. of 
Alberta, Edmonton, Alta., Canada T6G 
2G6, phone (403) 492-8250, fax (403) 492- 
7219. 


IPPS 92, Sixth Int'l Symp. on Paral- 
lel Processing: Mar. 23-26,1992, Bev¬ 
erly Hills, Calif. Submit six copies of com¬ 
plete paper by Sept. 16,1991, and camera- 
ready version by Jan. 17,1992, to Viktor 
Prasanna, IPPS 92, Electrical Eng.-Systems 
Dept., EEB 244, Univ. of Southern Cali¬ 
fornia, Los Angeles, CA 90089-2562, Inter¬ 
net ipps92@ashoka.usc.edu. 


Micro 24, 24th ACM/IEEE Int'l 
Symp. and Workshop on Microarchi¬ 
tecture: Nov. 18-20,1991, Albuquerque, 
N.M. Submit four copies of final version by 
Sept. 17, 1991, to (by geographical region) 
Andrew Wolfe, Electrical and Computer 
Science Dept., Carnegie Mellon Univ., 
Pittsburgh, PA 15213-3890, phone (412) 
268-7102, fax (412) 268-2860, e-mail 
wolfe@ece.cmu.edu; Toshio Nakatani, 

IBM Japan, 5-19, Sanbancho, Chiyoda-ku, 
Tokyo 102. Japan, phone 81 (03) 288-8409, 
fax 81 (03) 265-4251, e-mail nakatani@ 
trlvm3.iinusl.ibm.com or nakatani@ 
jpntscvm.bitnet; or Hans Mulder, Electri¬ 
cal Eng. Dept., Delft Univ. of Tech., PO 
Box 5031, 2600 GA Delft, The Nether¬ 
lands, phone 31 (0) 1578-5021, fax 31 (0) 
1578-4898, e-mail hansm@duteca.et. 
tudelft.nl. 


1992 IEEE Int’l Conf. on Robotics and 
Automation: May 10-15,1992, Nice, 
France. Sponsor: IEEE Robotics and Au¬ 
tomation Soc. Submit four copies of paper 
by Sept. 20,1991, to Georges Giralt, Labo¬ 
ratory d’lnformatique et d’Analyse des 
Systemes, 7, Avenue du Colonel Roche — 


30177 Toulouse Cedex, France, phone 33 
(61) 336-200, fax 33 (61) 553-577, e-mail 
giralt@laas.fr. 

Fifth Int’l Conf. on Putting into Practice 
Methods and Tools for Information System 
Design: Sept. 23-25,1992, Nantes, France. 
Submit five copies of paper by Sept. 30, 

1991, and camera-ready paper by May 1, 

1992, to Henri Habrias, Liana, IUT, 3 rue 
MI Joffre, 44041 Nantes Cedex Ol, France, 
phone (33) 4030-6056, fax (33) 4030-6001, 
e-mail habrias@naiut.dnet@ciripa.circe.fr. 

IEEE Software seeks articles for a 

special 1992 issue about the applica¬ 
tions of software-reliability models to as¬ 
sess and certify software quality and de¬ 
pendability during product development. 
Case studies and experience reports are 
particularly welcome. Submit seven copies 
of article by Oct. 1,1991, to Pradip K. Sri- 
mani or Yashwant K. Malaiya, Computer 
Science Dept., Colorado State Univ., Fort 
Collins, CO 80525, fax (303) 491-2293, In¬ 
ternet srimani@cs.colostate.edu or 
malaiya@cs.colostate.edu. For author 
guidelines, contact Karen Potes, IEEE 
Software, PO Box 3014, Los Alamitos, CA 
90720-1264, phone (714) 821-8380, fax 
(714) 821-4010, Internet w.c.ops@ 
compmail.com. 

IEEE Int’l Conf. on Wafer-Scale In- 
V&y tegration: Jan. 22-24,1992, San Fran¬ 
cisco. Sponsors: IEEE Computer Soc., 
IEEE Components, Hybrids, and Manu¬ 
facturing Tech. Soc. Submit six copies of 
full camera-ready text by Oct. 1,1991, to 
Peter W. Wyatt, MIT Lincoln Lab, B-153, 
Box 73, Lexington, MA 02173-9108, phone 
(617) 981-7232 (in the Americas); R. Mike 
Lea, Brunei Univ., Uxbridge UB8 3PH, 

UK (in Europe); or Tadashi Sasaki, Sharp 
Corp., 8, Ichigaya, Hachiman-cho, Shin- 
juku-ku, Tokyo 162, Japan (in Asia). 

Int’l J. of Computer Simulation plans a 
special issue on simulation of communica¬ 
tion systems. Publishers: Ablex. Submit 
five copies of full paper by Oct. 1,1991, to 
Jason Yi-Bing Lin or Victor Wing-Kit 
Mak, Bellcore, 445 South St., 2D-297, Mor¬ 
ristown, NJ 07962-1910, phone (201) 829- 
5095 or (201) 829-4470, fax (201) 984-5837, 
e-mail Iiny@mookie.bellcore.com or 
vicmak@dragon.bellcore.com. 

10th IEEE VLSI Test Symp.: Apr. 

7-9,1992, Atlantic City, N.J. Spon¬ 
sor: IEEE Computer Soc. Technical Com¬ 
mittee on Test Tech. Submit seven copies 
of extended summary or preferably full pa¬ 
per by Oct. 9,1991, and camera-ready ver¬ 
sion by Jan. 31, 1992, to Dhiraj Pradham, 
Univ. of Massachusetts, ECE Dept., Mar¬ 
cus Hall, Amherst, MA 01003, phone (413) 
545-0160, fax (413) 545-4611. 

12th Int’l Conf. on Distributed Com- 

puting Systems: June 9-12,1992, 
Yokohama, Japan. Cosponsor: Information 
Processing Soc. of Japan. Submit six copies 
of manuscript by Oct. 15,1991, to Joseph 
E. Urban, Computer Science and Eng. 
Dept., Arizona State Univ., Tyler Mall- 


ECG 252, Tempe, AZ 85287-5406, phone 
(602) 965-2774, fax (602) 965-2751, e-mail 
jurban@asuvax.eas.asu.edu. 

(£ji| PADS, Sixth Workshop on Parallel 

and Distributed Simulation: Jan. 20- 

22.1992, Newport Beach, Calif. Joint spon¬ 
sors: IEEE et al. Submit six copies of cam¬ 
era-ready copy by Oct. 15,1991. to Marc 
Abrams, Computer Science Dept., Virginia 
Tech, Blacksburg, VA 24061-0106, phone 
(703) 231-8457, fax (703) 231-6075, e-mail 
abrams@cs.vt.edu. 

IEEE Expert plans a special track on 

artificial intelligence in text-based in¬ 
formation systems. Submit four copies of 
the full manuscript by Oct. 25, 1991, to Dik 
L. Lee, Computer and Information Science 
Dept., Ohio State Univ., 2036 Neil Ave„ 
Columbus, OH 43210-1277, e-mail dlee@ 
cis.ohio-state.edu.; or W. Bruce Croft, 
Computer Science Dept., Univ. of Massa¬ 
chusetts, Lederle Graduate Research Cen¬ 
ter, Amherst, MA 01003, e-mail croft@cs. 
umass.edu. 

Second Int’l Conf. on Systems Inte- 

gration: June 15-18, 1992, Morris¬ 
town, N.J. Cosponsor: ACM. Submit six 
copies of complete paper and abstract by 
Oct. 25,1991, and final manuscript by Feb. 

17.1992, to Raymond T. Yeh, c/o Peter A. 
Ng, Computer and Information Science 
Dept., New Jersey Inst, of Tech., Univer¬ 
sity Heights, Newark, NJ 07102. 

Eighth Int’l Conf. and Workshop on 
vA' Data Eng.: Feb. 3-7, 1992, Phoenix, 
Ariz. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Data Eng. Submit five 
copies of camera-ready version by Oct. 31, 
1991, to Forouzan Golshanl, Computer Sci¬ 
ence and Eng. Dept., Arizona State Univ., 
Tempe, AZ 85287-5406, phone (602) 965- 
2855, e-mail golshani@asuvax.eas.asu.edu. 

Comp Euro 92, IEEE Int’l Conf. on 
v&Z Computer Systems and Software 
Eng.: May 4-8,1992, The Hague, The 
Netherlands. Cosponsors: IEEE Region 8, 
IEEE Benelux Section. Submit five copies 
of paper by Nov. 1,1991, and final manu¬ 
script by Feb. 1,1992, to Patrick Dewilde, 
Delft Univ. of Tech., EE Dept., POB 5031, 
2600 GA Delft, The Netherlands, phone 31 
(15) 785-089, fax 31 (15) 623-271. 

IEA/AIE 92, Fifth Int’l Conf. on In- 
v&Z dustrial and Eng. Applications of Ar¬ 
tificial Intelligence and Expert Systems: 

June 9-12,1992, Paderborn, Germany. Co¬ 
sponsors: Univ. of Paderborn et al. Submit 
six copies of paper by Nov. 1, 1991, and fi¬ 
nal copy by Mar. 16,1992, to Fevzi Belli, 
Univ. of Paderborn, Postfash 1621, 4790 
Paderborn, Germany, phone 49 (5251) 603- 
282, fax 49 (5251) 602-519, e-mail belli® 
adt.uni-paderborn.de. 

CGI 92, Computer Graphics Int’l 
W Conf.: June 22-26,1992, Tokyo. Co¬ 
sponsors: IEEE et al. Submit six copies of 
full paper by Nov. 8,1991, to T.L. Kunii, 
Information Science Dept., Univ. of To¬ 
kyo, 7-3-1 Hongo, Bunkyo-ku, Tokyo 113, 
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Japan, phone 81 (3) 3812-2111, ext. 4116, 
fax 81 (3) 3818-4607. 


Symp. on Assessment of Quality 
Software Development Tools: May 

27-29,1992, New Orleans. Sponsors: Tu- 
lane Univ. et al. Submit five copies of full 
paper by Nov. 27,1991, to Ez Nahouraii, 
IBM (798/089), 6321 San Ignacio Ave., San 
Jose, CA 95119, phone (408) 281-5741 
e-mail eznah@stlvm7.iinusl .ibm.com. 


IEEE Design & Test seeks papers 
(25 double-spaced pages, including 
figures) on general design, test, and manu¬ 
facturing topics by Dec. 1,1991, to Manuel 
d’Abreu, GE R&D. 1 River Rd., PO Box 
8, KW-C308, Schenectady, NY 12301, 
phone (518) 387-7097, fax (518) 387-5299, 
e-mail dabreu@crd.ge.com. 


{gfjN PCCC 92,11th IEEE Inti Phoenix 
Conf. on Computers and Communi¬ 
cations: Apr. 1-3, 1992, Scottsdale, Ariz. 
Cosponsors: IEEE Comm. Soc. et al. Sub¬ 
mit five copies of camera-ready version by 
Dec. 2, 1991. to Ming T. (Mike) Liu, Ohio 
State Univ., Computer and Information 
Science Dept., 2036 Neil Ave., Columbus, 
OH 43210-1277, phone (614) 292-6552, fax 
(614) 292-9021, e-mail mike.liu@osu.edu. 


IEEE Trans, on Software Eng. plans 
a special September 1992 issue on 
specification and analysis of real-time sys¬ 
tems. Submit five copies of full manuscript 
by Jan. 1, 1992, to Carlo Ghezzi, Diparti- 
mento di Elettronica, Politecnico di Mila¬ 
no, Piazza L. da Vinci, 32, 20133 Milano, 
Italy, phone 39 (2) 2399-3529, fax 39 (2) 
2399-3411, e-mail relett24@imipoli.bitnet 
or ghezzi@ipmel2.elet.polimi.it; or Richard 
A. Kemmerer, Reliable Software Group, 
Computer Science Dept., Univ. of Califor¬ 
nia, Santa Barbara, CA 93106, phone (805) 
893-4332, fax (805) 893-8553, e-mail 
kemm@cs.ucsb.edu. 


DCCA 3, Third Working Conf. on 
vS? 1 Dependable Computing for Critical 
Applications: Sept. 14-16,1992, Mondello, 
Sicily, Italy. Sponsor: Int’l Federation for 
Information Processing Working Group 
10.4. Submit six copies of paper by Jan. 31, 
1992, and camera-ready version by July 15, 
1992, to Carl Landwehr, Code 5540, Naval 
Research Lab, Washington, DC 20375- 
5000, phone (202) 767-3381, fax (202) 404- 
7942, e-mail landwehr@itd.nr.navy.mil. 


ICARCV 92, Second Int’l Conf. or 
vis? Automation, Robotics, and Com¬ 
puter Vision: Sept. 15-18,1992, Singapore. 
Cosponsors: Singapore Institution of Engi¬ 
neers et al. Submit 500-word extended 
summary by Feb. 29,1992, and final manu¬ 
script by May 31,1992, to ICARCV Secre¬ 
tariat, Associated Conventions and Exhibi¬ 
tions, 204 Bukit Timah Rd., #04-00, Boon 
Liew Bldg., Singapore 0922, phone (65) 
660-5399, fax (65) 732-6309, e-mail 
emital@ntivax>bitnet. 
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In the accompanying Calendar and adjoining Call for Papers, the IEEE 
Computer Society logo identifies the conferences the society is participat¬ 
ing in or sponsoring. Other conferences of interest to our readers — as well as 
their sponsors — are also listed. 

Calendar and Call for Papers notices are published free of charge, in chrono¬ 
logical order, and as space permits. 

When submitting information for inclusion in the Call for Papers section, please 
provide the following: the name of the event, the date(s), the location, the 
sponsor(s), the deadline for submittals, and the phone and fax numbers and — if 
applicable — the electronic address of the person to whom papers should be 
sent. 

For listings in the Calendar section, please provide the following: the event 
name, the date(s), the location, the sponsor(s), and the phone and fax numbers 
and — again, if applicable — the electronic address of the person to contact for 
complete information. 

Submitted information should arrive at Computer at least five weeks before 
the month of publication (i.e., for the October 1991 issue, send information for 
receipt by August 20,1991) to Chuck Governale, Calendar Dept., Computer, PO 
Box 3014, Los Alamitos, CA 90720-1264, fax (714) 821-4010, e-mail 
c.governale@compmail.com. 
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PODC 91,10th Symp. on Principles of 
Distributed Computing, Aug 19-21, Mont¬ 
real. Sponsor: ACM. Contact Luigi Lo- 
grippo. Computer Science Dept., Univ. of 
Ottawa, Ottawa, Ont., Canada KIN 6N5, 
phone (613) 564-5450, e-mail lmlsl@ 
uottawa. 


1991 Systems Evaluation and Assessment 
Tech. Workshop, Aug. 20-22, Silver 
Spring, Md. Sponsors: Naval Surface War¬ 
fare Center, Office of Naval Tech. Contact 
Janet Youngblood, NSWC, Code G42, 
10901 New Hampshire Ave., Silver Spring, 
MD 20903-5000, phone (301) 394-3851, fax 
(301) 394-1175, e-mail hwang@nswc-wo. 
navy.mil. 


HCI 91, Human Computer Interaction 
Conf., Aug. 20-23, Edinburgh, UK. Spon¬ 
sor: Human Computer Interaction Group 
of British Computer Society. Contact Brit¬ 
ish Informatics Soc., Unit 703/4, Delta 
Business Park, Great Western Way, Swin¬ 
don SN5 7XS, UK, phone 44 (793) 480-269, 
fax 44 (793) 480-270. 

IJCAI 91,12th Int’l Joint Conf. on Artifi¬ 
cial Intelligence, Aug. 24-30, Sydney, Aus¬ 
tralia. Cosponsors: Australian Computer 
Soc. et al. Contact Barbara J. Grosz, Aiken 
Computation Lab 20, Harvard Univ., 33 
Oxford St., Cambridge, MA 02138, phone 
(617) 495-3673, fax (617) 495-9837, e-mail 
grosz@endor.harvard.edu. 


j\ Hot Chips III, Symp. on High- 
' Performance Chips, Aug. 26-27, 


Stanford, Calif. Cosponsor: IEEE Com¬ 
puter Soc. Technical Committee on Micro¬ 
processors and Microcomputers. Contact 
Martin Freeman, Philips Research Labs, 
Signetics MS 02, 811 E. Arques Ave., 
Sunnyvale, CA 94086, phone (408) 991- 
3591, fax (408) 991-4077, e-mail 
mfreeman@sierra. stanford.edu; or Melissa 
Anderson, Silicon Graphics, 2011 N. Shore¬ 
line Blvd., PO Box 7311, Mountain View, 
CA 94039-7311, phone (415) 335-1565, fax 
(415) 965-7651, e-mail mda@sgi.com. 


jffil Tencon 91,1991 IEEE Region 10 
Conf., Aug. 26-30, New Delhi, India. 
Contact H.L. Bajaj, B-101 Hillview Apts., 
Vasant Aihar, New Delhi 110057, India, 
phone 91 (11) 36-0412, fax 91 (11) 36-1018; 
or A.L. Lakshminarasimhan, AT&T Bell 
Labs, 480 Red Hill Rd., No. HR 2E030, 
Middletown, NJ 07748, phone (201) 615- 
4524. 


1991 Workshop on the High-Order 
Language Theorem-Proving System 
and Its Applications, Aug. 27-30, Davis, 
Calif. Cosponsors: IEEE Computer Soc. 
Technical Committee on Design Automa¬ 
tion et al. Contact Myla Archer, Computer 
Science Division, Univ. of California at 
Davis, Davis, CA 95616, phone (916) 752- 
7583, fax (916) 752-4767, e-mail archer@ 
eecs.ucdavis.edu. 


SSD 91, Second Symp. on Large Spa- 
tial Databases, Aug. 28-30, Zurich, 
Switzerland. Contact Hans-J. Schek, Inst, 
fur Information Systeme, Eth Zentrum, 
CH-8092 Zurich, Switzerland, phone 41 (1) 
254-7240, fax 41 (1) 262-3973, e-mail 
schek@inf.ethz.ch. 
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September 1991 


^ ASAP 91, Int’l Conf. on Application- 
Specific Array Processors, Sept. 2-4, 

Barcelona, Spain. Sponsor: Princeton 
Univ. Contact S.Y. Kung, Electrical Eng. 
Dept., Princeton Univ., Princeton, NJ 
08554, phone (609) 258-3780, fax (609) 
258-3745. 


Eurographics 91, Conf. of the European 
Assoc, for Computer Graphics, Sept. 2-6, 

Vienna. Contact Eurographics 91, c/o In¬ 
terconvention, Austria Center Vienna, A- 
1450 Vienna, Austria, phone 43 (1) 2369- 
2643, fax 43 (1) 2369-648. 


{jgR} VLDB 91.17th Int’l Conf. on Very 
Large Data Bases, Sept. 3-6, Barce¬ 
lona, Spain. Cosponsors: IEEE Computer 
Soc. Technical Committee on Data Eng. 
et al. Contact Guy M. Lohman, IBM Al- 
maden Research Center, Dept. K55, Bldg. 
801, 650 Harry Rd., San Jose, CA 95120- 
6099, Internet lohman@ibm.com, Bitnet 
lohman@almaden. 


Meeting on Optical Fiber Materials and 
Devices, Sept. 3-6, Boston. Sponsor: Int’l 
Soc. for Optical Eng. Contact SPIE, PO 
Box 10, Bellingham, WA 98227-0010, 
phone (206) 676-3290, fax (206) 647-1445. 

SIGComm 91, ACM Conf. on Communica¬ 
tions Applications, Architectures, and Pro¬ 
tocols, Sept. 4-6, Zurich, Switzerland. Con¬ 
tact ACM, 11 W. 42nd St., New York, NY 
10036, phone (212) 869-7440. 

Int’l Workshop on Field Programmable 
Logic and Applications, Sept. 4-6, Oxford, 
England. Contact Will Moore, Eng. Sci¬ 
ence Dept., Univ. of Oxford, Parks Road, 
Oxford, OX1 3PJ, England, UK, phone 44 
(865) 270-373, fax 44 (865) 270-309, e-mail 
cpdmail@vax.ox.ac.uk. 


tact SPIE, PO Box 10, Bellingham, WA 
98227-0010, phone (206) 676-3290, fax 
(206) 647-1445. 

Second Govt. Neural Network Applica¬ 
tions Workshop, Sept. 10-12, Huntsville, 
Ala. Contact Rene Kirkwood, US Army 
Research Office, SLCRO-AO-A, PO Box 
12211, Research Triangle Park, NC 27709- 
2211, phone (919) 549-4341, fax (919) 549- 
4310. 

Int’l Conf. on the Performance of Distrib¬ 
uted Systems and Integrated Communica¬ 
tion Networks, Sept. 10-12, Kyoto, Japan. 
Sponsor: Int’l Federation for Information 
Processing. Contact Yutaka Takahashi, 
Applied Math, and Physics Dept., Faculty 
of Eng., Kyoto Univ., Kyoto 606, Japan, 
phone 81 (75) 3753-5493, fax 81 (75) 3761- 
2437, e-mail yutaka@kuamp.kyoto-u.ac.jp. 

Int’l Meeting on the History and Prehis¬ 
tory of Informatics and Automatic Com¬ 
puting, Sept. 10-12, Siena, Italy. Contact 
Corrado Bonfanti, c/o Insiel S.p.A., Via S. 
Francesco d’Assisi, 43,1-34133 Trieste, 
Italy, phone 39 (40) 359-9459, fax 39 (40) 
775-035. 


1991 Systems Design Synthesis Tech. 
Workshop, Sept. 10-13, Washington, DC. 
Cosponsors: Naval Surface Warfare Cen¬ 
ter, Office of Naval Tech. Contact Steve 
Howell, U33, NSWC, 10901 New Hamp¬ 
shire Ave., Silver Springs, MD 20903-5000, 
phone (301) 394-3987, fax (301) 394-1175, 
e-mail showell@nswc-wo.navy.mil. 


® Compsac 91,15th Int’l Computer 
Software and Applications Conf., 
Sept. 11-13, Tokyo. Sponsor: Information 
Processing Soc. of Japan. Contact Stephen 
S. Yau, Univ. of Florida, CIS Dept., Rm. 
301, Gainesville, FL 32611, phone (904) 
335-8006 or (904) 392-1212, fax (904) 392- 
1220, e-mail yau@cis.ufl.edu. 


Pais, 1096 Lisboa Codex, Portugal, phone 
351 (1) 801-579, fax 351 (1) 897-650, e-mail 
dl663@eta.ist.rccn.pt. 

Eur-Open, Autumn 1991 European Forum 
for Open Systems, Sept. 16-20, Budapest, 
Hungary. Contact Eur-Open Secretariat, 
Owles Hall, Buntingford, Herts. SG9 9PL, 
UK, phone 44 (763) 73039, fax 44 (763) 
73255, e-mail europen@eu.net. 

Int’l Conf. on Symbolic-Numeric Data 
Analysis and Learning, Sept. 17-20, Paris. 
Sponsor: Inst. Nat’l de Recherche en Infor- 
matique et en Automatique. Contact Conf. 
Secretariat, INRIA, Service des Relations 
Exterieures, Domaine de Voluceau — 
Rocquencourt, BP 105, 78153 Le Chesnay 
Cedex, France; phone 33 (l)-39-63-55-00, 
fax 33 (1) 39-63-56-38. 

Fourth Midwest Unix and Open Systems 
Conf., Sept. 18-19, Detroit. Contact Com¬ 
puter Solutions Expo, 1264 Bedford Rd., 
Grosse Pointe Park, MI 48230, phone (313) 
882-6539, fax (313) 822-6942, e-mail 
cs_expo@um.cc.umich.edu. 

Working Conf. on Security and Reliability 
in Distributed Systems, Sept. 18-20, Prince 
Edward County, Ont., Canada. Sponsor: 
IFIP. Contact Stewart Lee, Computer Sys¬ 
tems Research Inst., D.L. Pratt Bldg., 

Univ. of Toronto, 6 King’s College Rd., 
Toronto, Ont., Canada M5S 1A4, phone 
(416) 878-5035, fax (416) 978-4765, e-mail 
stew@hub.toronto.edu. 

Sixth Conf. on Measurement, Modeling, 
and Evaluation of Computer Systems, 

Sept. 18-20, Munich, Germany. Cospon¬ 
sors: Gesellschaft fur Informatik et al. 
Contact Axel or Fritz Lehmann, Fakultat 
fur Informatik, Univ. der Bundeswehr 
Miinchen, Werner-Heisenberg-Weg 39, D- 
8014 Neubiberg, Germany, phone 49 (89) 
6004-2648, fax 49 (89) 6004-3560. 


® Euro VHDL 91, Second European 
Conf. on Very High Density Logic, 
Sept. 8-11, Stockholm. Sponsor: Int’l Fed¬ 
eration for Information Processing. Con¬ 
tact Jean Mermet, IMT Technopole de 
Chateau-Gombert, 13451 Marseille, Cedex 
13, France, phone 33 (91) 05-44, fax 33 (91) 
05-4343. 


Third European Conf. on Electron and 
Optical-Beam Testing of Integrated Cir¬ 
cuits, Sept. 9-11, Como, Italy. Sponsor: 
IEEE North Italy Section. Contact Mar¬ 
cello Melgara, CSELT, via Reiss Romoli 
274,10148 Torino, Italy, phone 39 (11) 
2169-259, fax 39 (11) 2169-695. 

Third Conf. on Military Robotic Vehicles, 
Sept. 9-12, Medicine Hat, Alta., Canada. 
Cosponsors: Defence Research Establish¬ 
ment Suffield, Alberta Research Council. 
Contact Dave Mackay, DRES, Box 4000, 
Medicine Hat, Alta., Canada T1A 8K6, 
phone (403) 544-4732, fax (403) 544-3388. 

Tech. Symp. on Microelectronic Processing 
Integration, Sept. 9-13, San Jose, Calif. 
Sponsor: Int’l Soc. for Optical Eng. Con¬ 


ASEET, Sixth Ada Software Eng. Educa¬ 
tion and Training Symp., Sept., 11-13, Al¬ 
exandria, Va. Sponsor: AJPO. Contact 
Catherine W. McDonald, Inst, for Defense 
Analysis, 1801 N. Beauregard St., Alexan¬ 
dria, VA 22311, phone (703) 845-6626, fax 
(703) 845-6848, e-mail, mcdonald@ida.org. 

Al 91, Frontiers in Innovative Computing 
for the Nuclear Industry, Sept. 15-18, Jack- 
son, Wyo. Cosponsors: Am. Nuclear Soc. 
Idaho Section et al. Contact Richard W. 
Lindsay, Argonne Nat’l Lab, PO Box 2528, 
Idaho Falls, ID 83403-2528, phone (208) 
526-7754, fax (208) 526-7623. 

1991 Electronic Packaging Conf., Sept. 15- 

19, San Diego, Calif. Sponsor: Int’l Elec¬ 
tronics Packaging Soc. Contact IEPS, 114 
N. Hale St., Wheaton, IL 60187-5113, 
phone (708) 260-1044, fax (708) 260-0867. 

Compugraphics 91, First Int’l Conf. on 
Computational Graphics and Visualization 
Techniques, Sept. 16-20, Sesimbra, Portu¬ 
gal. Contact Harold P. Santo, Compu¬ 
graphics 91, Civil Eng. Dept., Inst, of Eng., 
Technical Univ. of Lisbon, Av. Rovisco 


AICS 91, Fourth Irish Conf. on Artificial 
Intelligence and Cognitive Science, Sept. 
19-20, Cork, Ireland. Contact Humphrey 
Sorensen, AICS 91, Computer Science 
Dept., Univ. College, Cork, Ireland, e-mail 
aics91@iruccvax.ucc.ie. 

Fourth Artificial Intelligence Symp., 
Sept. 20-21, Fredericton, N.B., Cana¬ 
da. Sponsor: Univ. of New Brunswick. 
Contact Bradford G. Nickerson, Computer 
Science Faculty, Univ. of New Brunswick, 
PO Box 4400, Fredericton, N.B., Canada 
E3B 5A3, phone (506) 453-4566, fax (506) 
453-3566, e-mail bgn@unb.ca. 

First Int’l Workshop on the Econom¬ 
ics of Design and Test, Sept. 23-25, 

Austin, Texas. Sponsor: ACM. Contact 
Sarma Sastry, EE Systems Dept, SAL 340, 
Univ. of Southern Calif., Los Angeles, CA 
90089-0781, phone (213) 743-0528, e-mail 
sastry@vishnu.usc.edu; or Magdy Abadir, 
MCC CAD Program, 3500 W. Balcones 
Center Dr., Austin, TX 78759, phone (512) 
338-3611, fax (512) 338-3600; or A.P. Am¬ 
bler, Brunei Univ., Dept, of Electrical Eng. 
and Electronics, Uxbridge, Middx, UB8 
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e-mail sarah_sieling@gate.ce.ohio-st; 


ASIC 91, Fourth IEEE Int’l Applica- 
fion-Spccific Integrated Circuits 

Conf., Sept. 23-27, Rochester, N.Y. Spon- October 1991 
sor: IEEE Rochester Section. Contact 
Lynne M. Engelbrecht, ASIC 91, 170 Mt. 

Read Blvd., Rochester, NY 14611, phone 
(716) 328-2310, fax (716) 436-9370. 


Pacific Rim Int’l Symp. on Fault- 

Tolerant Systems, Sept. 26-27, Ka¬ 
wasaki, Japan. Sponsor: Inst, of Electrical, 
Information, and Comm. Eng. Contact Sa- 
chio Naito, Electrical Eng. Dept., Nagaoka 
Univ. of Tech., 1603-1 Kamitomioka, Na¬ 
gaoka, Niigata, 940-21, Japan, phone 81 
(258) 46-6000, ext. 5110, fax 81 (258) 46- 
6506. 

Second Annual University /Industry Co¬ 
operation Conf., Sept. 29-30, Blacksburg, 
Va. Contact Susan Trulove, Virginia Tech 
Research Division, 309 Burruss Hall, 
Blacksburg, VA 24061-0244, phone (703) 
231-9356. 

Fifth SDL Forum, Sept. 29-Oct. 4, Glas¬ 
gow, Scotland. Sponsor: GEC Plessey 
Telecommunications. Contact Jo Gordon, 
Institution of Electrical Engineers, Savoy 
Place, London WC2R 0BL, UK., phone 44 
(71) 240-1871 , fax 44 (71) 240-7735. 

IEEE/ACIVI Int’l Conf. on Develop- 

ing and Managing Expert System 
Programs and Projects, Sept. 30-Oct. 2, 

Washington, DC. Contact Jerald Feinstein, 
Mitre, 7325 Colshire Dr., McLean, VA 
22102, phone (703) 883-6236, fax (703) 
821-0701; or Larry Medsker, Computer 
Science and Information Systems Dept., 
American Univ., Washington, DC 20016. 

10th Symp. on Reliable Distributed 
vU' Systems, Sept. 30-Oct. 2, Pisa, Italy. 
Contact Luca Simoncini, IEI-CNR, Via S. 
Maria 46, 56100 Pisa, Italy, phone 39 (50) 
553-159, fax 39 (50) 554-342; or Ozalp 
Babaoglu, Dip. di Matematica, Univ. di 
Bologna, Piazza di Porta S. Donato, 5, 
40127 Bologna, Italy, phone 39 (51) 354- 
430, fax 39 (51) 354-490, e-mail ozalp@ 
dm.unibo.il. 

First Int’l Conf. on Document Analy- 

sis and Recognition, Sept. 30-Oct. 2, 

Saint-Malo, France. Cosponsors: Assoc. 
Francaise pour la Cybemetique Eco- 
nomique et Technique et at. Contact AF- 
CET, 156 Bd Pdreire, 75017 Paris, France, 
phone (33) 1-4766-2419, fax (33) 1-4267- 
9312; or Guy Lorette, IRISA-Campus Uni- 
versitaire de Beaulieu, 35042 Rennes Ce- 
dex, France, phone (33) 9936-2000, fax (33) 
9938-32. 

ICAD 91, IFIP Working Conf. on Intelli¬ 
gent Computer-Aided Design, Sept. 30- 
Oct. 3, Columbus, Ohio. Sponsors: Int’l 
Federation for Information Processing et 
al. Contact Conferences and Institutes, 
Ohio State Univ., 175 Mount Hall, 1050 
Carmack Rd., Columbus, OH 43214, 
phone (614) 929-1301, fax (614) 292-0492, 


|£3j} FOCS, 32nd Foundations of Comput- 
er Science Conf., Oct. 1-3, San Juan, 
Puerto Rico. Sponsor: IEEE Computer 
Soc. Technical Committee on Mathemati¬ 
cal Foundations of Computing. Contact 
Christos Papadimitriou, CSE Dept., Univ. 
of California, San Diego, CA 92093, phone 
(619) 534-2086. 

Northcon 91, Oct. 1-3, Portland, Ore. Co¬ 
sponsors: IEEE Portland and Seattle Sec¬ 
tions et al. Contact Jon S. Potts, Northcon 
91, 8110 Airport Blvd., Los Angeles, CA 
90045-3194, phone (800) 877-2668 or (213) 
215-3976, ext. 251, fax (213) 641-5117. 

/£§^j IEEE Workshop on Visual Motion, 
Oct. 6-9, Princeton, N.J. Contact Pe¬ 
ter Burt, David Sarnoff Research Center, 
201 Washington Rd., Princeton, NJ 08540, 
e-mail burt@vision.sarnoff.com. 

OOPSLA 91, Sixth Conf. on Object-Ori¬ 
ented Programming Systems, Languages, 
and Applications, Oct. 6-11, Phoenix, Ariz. 
Sponsor: ACM. Contact John Richards, 
IBM T.J. Watson Research Center, PO 
Box 704, Yorktown Heights, NY 10598, 
phone (914) 784-7616; or Dan Steinbach, 
Steinbach and Co., 1 Pleasant St., May¬ 
nard, MA 01754, phone (508) 897-8661. 

|£§^j CSEE 91, Fifth Conf. on Software 
Eng. Education, Oct. 7-8, Pittsburgh. 
Sponsor: Software Eng. Inst. Contact 
James E. Tomayko, SEI, Carnegie Mellon 
Univ., 4500 Fifth Ave., Pittsburgh, PA 
15213-3890, phone (412) 268-6806, fax 
(412) 268-5758, e-mail jet@sei.cmu.edu. 

llth IEEE Symp. on Mass Storage 
Systems, Oct. 7-10, Monterey, Calif. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Mass Storage Systems and 
Tech. Contact Bernard T. O’Lear, NCAR, 
PO Box 3000, Boulder, CO 80307, phone 
(303) 497-1268, fax (303) 497-1137. 

Symp. on Testing, Analysis, and Ver- 
ification, Oct. 8-10, Victoria, B.C., 
Canada. Sponsors: IEEE Computer Soc., 
ACM SIGSoft. Contact Nancy Leveson, 
Computer Science Dept., Univ. of Califor¬ 
nia, Irvine, CA 92717, phone (714) 856- 
5517, e-mail nancy@ics.uci.edu. 

First Int’l Conf. on Artificial Intelli- 
gence Applications on Wall St., Oct. 
9-11, New York City. Sponsor: Polytechnic 
Univ., Brooklyn. Contact Mary Bianchi, 
Polytechnic Univ., 333 Jay St., Brooklyn, 
NY 11201, phone (718) 260-3360, fax (718) 
260-3136. 

IEEE Int’l Workshop on Visual Lan- 
vS' guages, Oct. 9-11, Kobe, Japan. 
Sponsor: IEEE Computer Soc. Contact 
Shi-Kuo Chang, Computer Science Dept., 


Univ. of Pittsburgh, Pittsburgh, PA 15260, 
phone (412) 624-8423, fax (412) 624-8465. 

Workshop on Experimental Distrib- 
uted Systems, Oct. 12, Huntsville, 
Ala. Contact Raif M. Yanney, TRW, 1 
Space Park, DH2/2328, Redondo Beach, 
CA 90278, phone (213) 764-6033. 

ICCD 91, IEEE Int’l Conf. on Com- 
puter Design, Oct. 14-16. Cambridge, 
Mass. Cosponsors: IEEE Computer Soc. 
and IEEE Circuits and Systems Soc. Con¬ 
tact ICCD 91, IEEE Computer Soc., 1730 
Massachusetts Ave. NW, Washington, DC 
20036-1903, phone (202) 371-1013. 

® 16th Conf. on Local Computer Net¬ 
works, Oct. 14-17, Minneapolis, 

Minn. Sponsor: IEEE Computer Soc. 
Technical Committee on Computer Comm. 
Contact James F. Mollenauer, Technical 
Strategy Associates, 37 Silver Birch Rd., 
Newton, MA 02168, phone and fax (617) 
244-0077. 

CSM 91, Conf. on Software Mainte- 
nance, Oct. 14-17, Sorrento, Italy. 
Sponsor: IEEE. Contact Vaclav Rajlich, 
Computer Science Dept., Wayne State 
Univ., Detroit, MI 48202, phone (313) 577- 
5423, fax (313) 577-6868, e-mail vtr@cs. 
wayne.edu; John Munson, Computer Sci¬ 
ence Dept., Univ. of West Florida, Pensa¬ 
cola, FL 32514; or Malcolm Munro, Centre 
for Software Maintenance, Univ. of 
Durham, Durham, DH1 3LE, England, 
phone 44 (091) 374-2634, e-mail malcolm. 
munro@uk.ac.durham. 

/£ji) RIDT 91, Second Int’l Workshop on 
Raster Imaging and Digital Typogra¬ 
phy, Oct. 15-16, Boston. Sponsor: Univ. of 
Massachusetts. Contact Robert A. Morris, 
Math, and Computer Science Dept., Univ. 
of Massachusetts at Boston, Harbor Cam¬ 
pus, Boston, MA 02125-3393, phone (617) 
287-6466, e-mail ridt91-request@cs.umb. 
edu. 

Int’l Workshop on Object Orienta- 
tion in Operating Systems, Oct. 17- 

18, Palo Alto, Calif. Sponsor: IEEE Com¬ 
puter Soc, Technical Committee on Oper¬ 
ating Systems. Contact Vincent Russo, 
Computer Science Dept., Purdue Univ., 
West Lafayette, IN 47907, phone (317) 
494-6008, fax (317) 494-0737. 

/iji) Visualization 91, Oct. 22-25, San 

v&z Diego, Calif. Sponsor: IEEE Com¬ 
puter Soc. Technical Committee on Com¬ 
puter Graphics. Contact Bruce Brown, Or¬ 
acle, 500 Oracle Pkwy., MD 40P12, Red¬ 
wood Shores, CA 94065, phone (415) 726- 
0983, fax (415) 506-7200; or Gregory M. 
Nielson, Computer Science Dept., Arizona 
State Univ., Rural Road and University, 
Tempe, AZ 85287-5406, phone (602) 965- 
2785. 

10th Int’l Conf. on Entity-Relation- 
ship Approach, Oct. 23-25, San Fran¬ 
cisco. Sponsor: ER Inst, et al. Contact Ter¬ 
ry Moriarty, Bank of Am., PO Box 37000, 
#3439, San Francisco, CA 94137, phone 
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(415) 675-5250; or Toby J. Teorey, EECS 
Dept., Univ. of Michigan, Ann Arbor, MI 
48109-2122, phone (313) 763-5216, e-mail 
teorey@ub.cc.umich.edu. 

Sixth Int’l Workshop on Software 

Specification and Design, Oct. 25-26, 

Como, Italy. Contact C. Ghezzi, Dip. di 
Elettronica, Politecnico di Milano, Piazza 
Leonardo Da Vinci 32,20133 Milano, Ita¬ 
lia, e-mail rele»24@imipoli.bitnet; or Jean- 
Pierre Finance, CRIN, Campus Scienti- 
fique, BP 239 54000 Nancy, France, e-mail 
finance@loria.crin.fr. 

ITC 91, Int’l Test Conf., Oct. 26-Nov. 

l, Nashville, Tenn. Sponsor: IEEE 
Philadelphia Section. Contact Doris Tho¬ 
mas, PO Box 264, Mt. Freedom, NJ 07970, 
phone (201) 895-5260, fax (201) 896-7265; 
or IEEE Computer Soc., 1730 Massachu¬ 
setts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 

ILPS 91, Int'l Logic Programming 
Vi/ Symp., Oct. 28-31, San Diego, Calif. 
Sponsor: Assoc, of Logic Programming. 
Contact Kenneth Kahn or Vijay Saraswat, 
Xerox PARC, 3333 Coyote Hill Rd., Palo 
Alto, CA 94304, Kahn’s phone (415) 494- 
4390, Saraswat’s phone (415) 494-4747, fax 
(415) 494-4334, e-mail ilps91@parc.xerox. 


® ISCIS VI, Sixth Int’l Symp. on Com¬ 
puter and Information Sciences, Oct. 
30-Nov. 2, Ankara, Turkey. Sponsors: Bil- 
kent Univ., IEEE Turkey Chapter. Con¬ 
tact Mehmet Baray, Bilkent Univ., Com¬ 
puter Eng. and Information Sciences 
Dept., Bilkent 06533 Ankara, Turkey, fax 
90 (4) 266-4127, e-mail iscis@trbilun.bitnet. 


November 1991 

25th Asilomar Conf. on Signals, Sys- 
terns, and Computers, Nov. 4-6, Pa¬ 
cific Grove, Calif. Sponsors: Naval Post¬ 
graduate School, San Jose State Univ. 
Contact Frederic J. Harris, Electrical and 
Computer Eng. Dept., San Diego State 
Univ., San Diego, CA 92182-0190, (619) 
594-6162. 

(£jj\ TAI 91, Third IEEE Computer Soc. 

Conf. on Tools for Artificial Intelli¬ 
gence, Nov. 5-8, San Jose, Calif. Contact 
Benjamin Wah, Coordinated Science Lab, 
MC 228, Univ. of Illinois, 1101 W. Spring- 
field Ave., Urbana, IL 61801-3082, phone 
(217) 333-3516, fax (217) 244-1764, e-mail 
wah% aquinas@cso.uicu.edu; or Nikolaus 
G. Bourbakis, 4138 Moonflower Ct., San 
Jose, CA 95135, phone (408) 270-3455. 

(fro Conf. on Organizational Computing 
Systems, Nov. 5-8, Atlanta. Sponsors: 
IEEE Computer Soc. Technical Commit¬ 
tee on Office Automation, ACM SIGOIS, 
Int’l Federation for Information Process¬ 
ing. Contact Frederick H. Lochovsky, 

Hong Kong Univ. of Science and Tech., 
Computer Science Dept., 5/F World Ship¬ 


ping Center, 7 Canton Rd., Hong Kong, 
phone (852) 302-1642, fax (852) 736-8801. 

Conf. on Fuzzy and Neural Systems and 
Vehicle Applications, Nov. 8, Tokyo. Co¬ 
sponsors: IEEE Industrial Electronics Soc., 
Japan Soc. for Fuzzy Theory and Systems. 
Contact Ichiro Masaki, Computer Science 
Dept., General Motors Research Labs, 
30500 Mound Rd., Warren, MI 48090-9055, 
phone (313) 986-1466, fax (313) 986-9356, 
CSnet masaki@gmr.com. 

® ICCAD 91, IEEE Int’l Conf. on 

Computer-Aided Design, Nov. 11-14, 

Santa Clara, Calif. Sponsor: IEEE Circuits 
and Systems Soc. Contact ICCAD 91 Sec¬ 
retary, MP Associates, 7490 Clubhouse 
Rd., Suite 102, Boulder, CO 80301, phone 
(303) 530-4562. 

Micro 24, 24th ACM/IEEE Int'l 
Symp. and Workshop on Microarchi¬ 
tecture, Nov. 18-20, Albuquerque, N.M. 
Contact Yashwant K. Malaiya, Computer 
Science Dept., Colorado State Univ., Fort 
Collins, CO 80523, phone (303) 491-7031, 
fax (303) 491-2293, e-mail malaiya@ravi. 
cs.colostate.edu. 

1991 IEEE Int’l Workshop on Defect 
and Fault Tolerance in VLSI Sys¬ 
tems, Nov. 18-20, Hidden Valley, Pa. Con¬ 
tact Wojciech Maly, Electrical and Com¬ 
puter Eng. Dept., Carnegie Mellon Univ., 
5000 Forbes Ave., Pittsburgh, PA 15213- 
3890, phone (412) 268-6637, fax (412) 268- 
2860, e-mail maly@ece.cmu.edu. 

Supercomputing 91, Nov. 18-22, 

Albuquerque, N.M. Cosponsor: 

ACM. Contact Raymond L. Elliott, Com¬ 
puting and Comm. Div., MS B260, Los 
Alamos Nat’l Lab, Los Alamos, NM 87545, 
phone (505) 667-1449, fax (505) 665-4361, 
e-mail rle@lanl.gov; or Supercomputing 91, 
IEEE Computer Soc., 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 


December 1991 


CTM Third IEEE Int’l Symp. on Parallel 
v*? and Distributed Processing, Dec. 1-5, 

Dallas. Sponsors: IEEE Computer Soc., 
IEEE Dallas Section, ACM SIGArch. 
Contact Sartaj Sahni, CIS Dept., CSE 301, 
Univ. of Florida, Gainesville, FL 32611, 
phone (904) 392-1527, fax (904) 392-1220; 
or Behrooz Shirazi, Univ. of Texas at Ar¬ 
lington, Computer Science Eng. Dept., 

Box 19015, Arlington, TX 76019-0015, 
phone (817) 273-3605, fax (817) 273-2548, 
e-mail shirazi@evax.utarl.edu. 

® 12th IEEE Symp. on Real-Time Sys¬ 
tems, Dec. 3-6, San Antonio, Texas. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Real-Time Computing. 
Contact Jane S.W. Liu, Computer Science 
Dept., Univ. of Illinois, 1304 W. Spring- 
field Ave., Urbana, IL 61801, phone (217) 
333-0135, e-mail janeliu@cs.uiuc.edu. 


Int’l Conf. on Parallel and Distribut- 
ed Information Systems, Dec. 4-6, 

Miami Beach, Fla. Cosponsors: IEEE 
Computer Soc. et al. Contact Amit Sheth, 
Bellcore, 1J-210, 444 Hoes Ln., Piscataway, 
NJ 08854, phone (908) 699-3300, fax (908) 
699-9011, e-mail amit@ctt.bellcore.com. 

(£|ji 1991 Winter Simulation Conf., Dec. 

8-11, Phoenix, Ariz. Sponsor: ACM. 
Contact Robert Crain, Wolverine Soft¬ 
ware, 4115 Annandale Rd., Suite 200, An- 
nandale, VA 22003. 

World Congress on Expert Systems, 
vl?' Dec. 16-19, Orlando, Fla. Cospon¬ 
sors: Int’l Assoc, of Knowledge Engineers 
et al. Contact World Congress on Expert 
Systems, c/o Congress Secretariat, Congrex 
(USA), 7315 Wisconsin Ave., Suite 404E, 
Bethesda, MD 20814, phone (301) 469- 
3355, fax (301) 469-3360. 


January 1992 

® Fifth Int’l Conf. on VLSI Design, 
Jan. 4-7, Bangalore, India. Sponsor: 
VLSI Soc. of India et al. Contact Asoke K. 
Laha, Cadence Design Systems, Systems 
Division, 2 Lowell Research Center Dr., 
Lowell, MA 01852-4995, phone (508) 934- 
0233, fax (508) 441-1109, e-mail laha@ 
cadence.com; or Lalit M. Patnaik, Com¬ 
puter Science and Automation, Indian 
Inst, of Science, Bangalore, 560012, India, 
phone 91 (812) 342-451, e-mail lalit% 
vigyan@shakti.emet.in. 

Hawaii Int’l Conf. on Systems Sci- 
ences, Jan. 7-10, Koloa, Hawaii. Co¬ 
sponsors: IEEE, ACM. Contact Luqi, 
Computer Science Dept, Naval Postgradu¬ 
ate School, Monterey, CA 93940, phone 
(408) 646-2468. 

/QjN PADS, Sixth Workshop on Parallel 
and Distributed Simulation, Jan. 20- 

22, Newport Beach, Calif. Joint sponsors: 
IEEE, ACM, Soc. for Computer Simula¬ 
tion. Contact Paul Reynolds, Computer 
Science Dept., Olsson Hall, Univ. of Vir¬ 
ginia, Charlottesville, VA 22903, phone 
(804) 924-1039, e-mail pfr@louisxiv.ipc. 
virginia.edu. 

IEEE Int’l Conf. on Wafer-Scale In- 

tegration, Jan. 22-24, San Francisco. 
Sponsors: IEEE Computer Soc., IEEE 
Components, Hybrids, and Manufacturing 
Tech. Soc. Contact Peter W. Wyatt, MIT 
Lincoln Lab, B-153, Box 73, Lexington, 
MA 02173-9108, phone (617) 981-7232. 

SETA 2, Second Int’l Symp. on Envi- 
ronments and Tools for Ada, Jan. 28- 

31, Washington, DC. Cosponsors: IEEE 
Computer Soc. Technical Committee on 
Computer Languages. Contact Patricia 
Orbernborg, NADC Code 7031, Warmin¬ 
ster, PA 18974-5000, phone (215) 441-2737, 
e-mail tricia@nadc.navy.mil. 


August 1991 






February 1992 

ICDE 92, Eighth Int’l Conf. and 
Workshop on Data Eng., Feb. 1-7, 

Phoenix, Ariz. Sponsor: IEEE Computer 
Soc. Technical Committee on Data Eng. 
Contact (for the conference) Nick J. Cer- 
cone. Center for Systems Sciences, Simon 
Fraser Univ., Burnaby, B.C., Canada V5A 
1S6, phone (604) 291-4588 or 3229, fax 
(604) 291-4951, e-mail nick@cs.sfu.ca; or 
(for the workshop on research issues) 
Clement Yu, Electrical Eng. and Computer 
Science Dept., Univ. of Illinois at Chicago, 
Chicago, IL 60680, phone (312) 996-2318, 
fax (312) 413-0024. 

/gji RIDE 92, Int’l Workshop on Re- 
search Issues in Data Eng., Feb. 2-3, 

Mission Palms, Ariz. Contact Clement Yu, 
EECS Dept., Univ. of Illinois at Chicago, 
Chicago, IL 60680, phone (312) 996-2318, 
fax (312) 413-0024, e-mail yu@uicbert. 
eecs.uic.edu. 

ISSCC 92,1992 IEEE Int’l Solid-State Cir¬ 
cuits Conf., Feb. 19-21, San Francisco. 
Sponsors: IEEE Solid-State Circuits Coun¬ 
cil et al. Contact Diane Suiters, Courtesy 
Associates, 655 15th St. NW, Suite 300, 
Washington, DC 20005, phone (202) 639- 
4255. 

tgji Compcon Spring 92, Feb. 24-28, San 

Francisco. Contact Compcon Spring 
92, IEEE Computer Soc., 1730 Massachu¬ 
setts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 


March 1992 


{jgj) CAIA 92, Eighth IEEE Conf. on Ar- 
tificial Intelligence for Applications, 
Mar. 2-6, Monterey, Calif. Contact CAIA 
92, IEEE Computer Soc., 1730 Massachu¬ 
setts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013, fax (202) 728- 
0884. 

Third Int’l Conf. on Data and 
Knowledge Systems for Manufactur¬ 
ing Eng., Mar. 9-13, Villeurbanne, France. 
Cosponsors: Assoc. Francaise pour la Cy- 
bernetique Economique et Technique et 
al. Contact INSA, 20 Av. Albert Einstein, 
69621 Villeurbanne, France, phone 33 (72) 
438-172, fax 33 (72) 440-800. 

Fourth Int’l Conf. on Strategic Soft- 

vSP ware Systems, Mar. 10-11, Hunts¬ 
ville, Ala. Cosponsors: IEEE Computer 
Soc. Huntsville Chapter, Univ. of Alabama 
in Huntsville. Contact Ann H. Yelle, Univ. 
of Alabama in Huntsville, Continuing Edu¬ 
cation Division, Conferences (SSS-92), 
Bevill Center 289-A, Huntsville, AL 35899, 
phone (800) 448-4035 or (205) 895-6372, 
fax (205) 895-6760. 

(gi) Fifth Virus and Security Conf., Mar. 
11-13, New York City. Sponsor: Data 


Processing Management Assoc. Financial May 1992 
Industries. Contact Judy S. Brand, PO Box 
6313 FDR Station, New York, NY 10150, 
phone (800) 835-2246, ext. 190, fax (303) 

825-9151. 


/g^i ED AC 92, European Conf. on De¬ 
vi^ sign Automation, Mar. 16-19, Brus¬ 
sels. Cosponsors: ED AC Assoc, et al. Con¬ 
tact EDAC 92 Secretariat, CEP Consult¬ 
ants, 26-28 Albany St., Edinburgh EH1 
3QH, UK, phone 44 (31) 557-2478, fax 44 
(31) 557-5749. 

(gi) Second Conf. on Computers, Free- 
V5P dom, and Privacy, Mar. 18-20, Wash¬ 
ington, DC. Cosponsors: ACM et al. Con¬ 
tact Lance Hoffman, George Washington, 
Univ., Electrical Eng. and Computer Sci¬ 
ence Dept., Washington, DC 20052, phone 
(202) 994-4955. 

jg^ IPPS 92, Sixth Int’l Parallel Process- 
v&y ing Symp., Mar. 23-26, Beverly Hills, 
Calif. Contact Larry H. Canter, Computer 
Systems Approach, 1140 S. Raymond Ave., 
Suite B, Fullerton, CA 92631, phone (714) 
738-3414, fax (714) 738-3470. 


April 1992 

(gjj) PCCC 92,11th IEEE Int'l Phoenix 
v3✓ Conf. on Computers and Communi¬ 
cations, Apr. 1-3, Scottsdale, Ariz. Cospon¬ 
sors: IEEE Comm. Soc. et al. Contact 
Ralph Martinez, Univ. of Arizona, Electri¬ 
cal and Computer Eng. Dept., Tucson, AZ 
85721, phone (602) 621-6174, e-mail 
martinez%ecevax@rvax.ccit.arizona.edu; 
or Joseph Urban, Computer Science and 
Eng. Dept., Arizona State Univ., Tyler 
Mail-ECG 252, Tempe, AZ 85287-5406, 
phone (602) 965-2774, fax (602) 965-2751, 
e-mail jurban@asuvax.eas.asu.edu. 

/gi) 10th IEEE VLSI Test Symp., Apr. 
v*? 7.9, Atlantic City, N.J. Sponsor: 

IEEE Computer Soc. Technical Commit¬ 
tee on Test Tech. Contact Dhiraj Pradham, 
Univ. of Massachusetts, ECE Dept., Mar¬ 
cus Hall, Amherst, MA 01003, phone (413) 
545-0160, fax (413) 545-4611. 

(g^) ICCL 92, Int’l Conf. on Computer 
vS/ Languages, Apr. 20-23, San Fran¬ 
cisco. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Computer Languages. 
Contact Mario Barbacci, Software Eng. 
Inst., Carnegie Mellon Univ., Pittsburgh, 
PA 15213, phone (412) 268-7704, fax (412) 
268-5758, e-mail barbacci@sei.cmu.edu. 

® Third Workshop on Workstation Op¬ 
erating Systems, Apr. 23-24, Key 

Biscayne, Fla. Sponsor: IEEE Computer 
Soc. Technical Committee on Operating 
Systems. Contact Joseph Boykin, Encore 
Computer, 257 Cedar Hill St., Marlbor¬ 
ough, MA 01752, phone (508) 460-0500, 
fax (508) 485-0709. 


CHI 92, Conf. on Human Factors in 
viy Computing, May 3-7, Monterey, 

Calif. Sponsor: ACM. Contact Assoc, for 
Computing Machinery, 11 W. 42nd St., 

New York, NY 10036, phone (212) 869- 
7440. 

/g£\ IEEE Infocom 92,11th Conf. on 
Computer Comm., May 4-8, Flo¬ 
rence, Italy. Cosponsor: IEEE Comm. Soc. 
Contact L. Fratta, Politecnico di Milano, 
c/o Cefriel, Via Emanueli, 15, 20126 Mi¬ 
lano, Italy, phone 39 (2) 2399-3578, fax 39 
(2) 2399-3587, e-mail fratta@imicefr.bitnet; 
or J. Kurose, Computer and Information 
Science Dept., Univ. of Massachusetts, 
Amherst, MA 01003, phone (413) 545- 
1585, e-mail kurose@cs.umass.edu. 

® Comp Euro 92, IEEE Int’l Conf. on 
Computer Systems and Software 
Eng., May 4-8, The Hague, The Nether¬ 
lands. Cosponsors: IEEE Region 8, IEEE 
Benelux Section. Contact G. Arink, Philips 
Medical Systems, PO Box 10000, 5680 DA 
Best, The Netherlands, phone 31 (40) 762- 
060, fax 31 (40) 762-952. 

|g^) ICSE 92,14th Int’l Conf. on Soft- 
ware Eng., May 11-15, Melbourne, 
Australia. Cosponsors: IEEE Computer 
Soc. Technical Committee on Software 
Eng. et al. Contact A.Y. Montgomery, 
Computer Science Dept., Royal Mel¬ 
bourne Inst, of Tech., PO Box 2476V, Mel¬ 
bourne 3001, Victoria, Australia, phone 61 
(3) 660-2943, fax 61 (3) 662-1617, e-mail 


|gj\ 22nd Int’l Symp. on Multiple-Valued 
Logic, May 27-29, Sendai, Japan. 
Sponsors: IEEE Computer Soc. Technical 
Committee on Multiple-Valued Logic. 
Contact Tatsuo Higuchi, EE Dept., To- 
huku Univ., Aoba, Aramaki, Sendai 980, 
Japan, phone (022) 222-1800. 


June 1992 

DAC 92, IEEE/ACM Design Auto- 
va? mation Conf., June 8-12, Anaheim, 
Calif. Contact DAC 92, MP Associates, 
7490 Clubhouse Rd., Boulder, CO 80301, 
phone (303) 530-4333. 

( g^l 12th Int’l Conf. on Distributed Com- 
NE7 puting Systems, June 9-12, Yokoha¬ 
ma, Japan. Cosponsor: Information Pro¬ 
cessing Soc. of Japan. Contact Ming T. 
(Mike) Liu, Computer and Information 
Science Dept., Ohio State Univ., 2036 Neil 
Ave., Columbus, OH 43210-1277, phone 
(614) 292-6552, fax (614) 292-9021, e-mail 
mike.liu@osu.edu; or Yutaka Matsushita, 
Instrumentation Eng. Dept., Keio Univ., 3- 
14-1 Hiyoshi, Kohoku-ku, Yokohama, Ja¬ 
pan 223, phone 81 (045) 563-1141, ext. 
3564, fax 81 (045) 562-7625, e-mail on@ 
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DCCA-3 Call for Papers 

3rd IFIP Working Conference on 

Dependable Computing for Critical Applications 

Can we rely on computers? 

Splendid Hotel La Torre, Mondello (Palermo), Sicily, Italy 

Organized by 14 . 16 September 1992 

IFIP Working Group 10.4 on Dependable Computing and Fault Tolerance 
In cooperation with 

IFIP Technical Committee 11 on Security and Protection in Information Processing Systems 
IEEE Computer Society Technical Committee on Fault-Tolerant Computing 
EWICS Technical Committee 7 on Systems Reliability, Safety and Security 
University of Pisa 

Istituto di Elaborazione dell'Informazione del CNR, Pisa 
Associazione Italiana per l'lnformatica ed il Calcolo Automatico 



General Chair 

L. Simoncini 
University of Pisa, Italy 

Program co-Chairs 

C. E. Landwehr 

Naval Research Laboratory, USA 
B. Randell 

University of Newcastle upon Tyne, UK 
Local Arrangements Chair 

E. Ricciardi, IEI-CNR, Italy 
Program Committee 

J. A. Abraham, U of Texas, USA 
P. Bishop, National Power, UK 

A. Costes, LAAS-CNRS, France 

D. Craigen, Odyssey Research, Canada 

K. Dittrich, U of Zurich, Switzerland 
H. Ihara, Hitachi, Japan 

R.K. Iyer, U of Illinois, USA 
J.P. Kelly, U of California, USA 

R. Kemmerer, U of California, USA 

H. Kopetz, Technische U Wien, Austria 
J.H. Lala, CS Draper Lab, USA 

K Levitt, U of California, USA 

B. Littlewood, City U, UK 
T. Lunt, SRI Inti, USA 

J. Meyer, U of Michigan, USA 

M. Morganti, Italtel, Italy 

S. Natkin, CNAM, France 

J-J. Quisquater, Philips, Belgium 
R.D. Schlichting, U of Arizona, USA 

F. B. Schneider, Cornell U, USA 

D. Siewiorek, Camegie-Mellon U, USA 

L. Strigini, IEI-CNR, Italy 

I. Sutherland, ORA, USA 

W.M. Turski, Warsaw U, Poland 
Ex Officio 

J-C. Laprie, LAAS-CNRS, France 
IFIP WG 10.4 Chair 


DCCA-3 is held in conjunction with the 
12th IFIP World Congress (Madrid, Spain, 
7-11 September 1992) 


Increasingly, individuals and organizations are becoming critically 
dependent on sophisticated computing systems. In differing 
circumstances, this dependency might for example center on the 
continuity of service received from the computing system, the overall 
performance level achieved, the real-time response rate provided, the 
extent to which catastrophic failures are avoided, or confidentiality 
violations prevented. The notion of dependability, defined as the 
trustworthiness of computer service such that reliance can justifiably be 
placed on this service, enables these various concerns to be subsumed 
within a single conceptual framework — with reliability, availability, safety 
and security, for example, being treated as particular attributes of 
dependability. This, the third IFIP Working Conference on the topic of 
Dependable Computing for Critical Applications, aims to 
continue the very successful tradition created by its predecessors (1989: 
Santa Barbara, California and 1991: Tucson, Arizona). It will thus provide 
a venue for the presentation and detailed discussion of research and 
advanced development relating to theory, techniques and tools for 
specifying, designing, implementing, assessing, validating, operating 
and maintaining critical computing systems. Of particular, but not 
exclusive, interest will again be presentations which address 
combinations of dependability attributes, e.g. safety and security, 
through studies of either a theoretical or an applied nature. 


Submitting a Paper: Six copies (in English) of original work should be 
submitted by 31 January 1992, to the Program co-Chair: 

Dr. Carl E. Landwehr 
Code 5540 

Naval Research Laboratory Tel: +(1) 202 767 33 81 

Washington, DC 20375-5000 Fax: +(1) 202 404 79 42 

USA E-mail: landwehr@itd.nrl.navy.mil 

Papers should be limited to 6000 words, full page figures being counted as 300 
words. Each paper should include a short abstract and a list of keywords 
indicating subject classification. Papers will be refereed and the final choice will 
be made by the Program Committee. Notification of acceptance will be sent by 25 
May 1992, and camera-ready copy will be due on 15 July 1992. A digest of 
papers will be available at the Conference, and hardbound proceedings will be 
published after the Conference as a volume of the Springer-Verlag series on 
Dependable Computing and Fault-Tolerant Systems. 


Important Dates: 

Submission deadline: 31 January 1992 
Acceptance notification: 25 May 1992 
Camera-ready copy due: 15 July 1992 







CAREER OPPORTUNITIES 


RATES: $12.00 per line, (ten lines mini¬ 
mum). Average five typeset words per 
line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified Adver¬ 
tising, COMPUTER Magazine, 10662 
Los Vaqueros Circle, PO Box 3014, Los 
Alamitos, CA 90720-1264; (714) 821- 
8380; fax:(714) 821-4010. 

In order to conform to the Age Discrimina¬ 
tion in Employment Act and to discourage 
age discrimination, COMPUTER may reject 
any advertisement containing any of these 
phrases or similar ones: "...recent college 
grads...," "...1-4 years maximum experi¬ 
ence.../' "...up to 5 years experience," or 
"...10 years maximum experience." COM¬ 
PUTER reserves the right to append to any 
advertisement without specific notice to the 


minimum requirements, not maximums. 
COMPUTER assumes that since advertisers 
have been notified of this policy in advance, 
they agree that any experience require¬ 
ments, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


AUBURN UNIVERSITY 

Earle C. Williams Eminent Scholar 
Chair in Electrical Engineering 

Nominations and applications are invited 
for the Earle C. Williams Eminent Scholar 
Chair in Electrical Engineering. Candidates 
for this chair should have achieved national 
and international prominence in digital sys¬ 
tems and/or microelectronics. 

Applicants or nominees must have an 
earned doctorate, senior academic experi¬ 
ence, and a documented record of distinc¬ 
tion in university teaching and research. The 
successful candidate will be expected to pro¬ 
vide intellectual leadership in his/her area of 
expertise for the Department of Electrical 
Engineering as well as enrich the scholarly 
environment at Auburn University. 

Auburn University is located in the city of 
Auburn in east-central Alabama. This land- 
grant university enrolls more than 21,000 
students, the largest on-campus enrollment 
in the state. The Department of Electrical 
Engineering, one of eight departments 
within the College of Engineering, offers 
Bachelor, Master, Master of Science and 
Ph.D. degrees in Electrical Engineering. The 
department has a current enrollment of 939 


undergraduate students and 100 graduate 
students. The 28 full-time faculty have an 
annual research expenditure of approxi¬ 
mately $2 million. 

The Search Committee will begin its re¬ 
view of applications immediately. Interested 
candidates should submit: (1) a detailed 
resume, (2) a letter indicating an interest in 
the chair, the candidates’s academic philo¬ 
sophy, and a brief statement of accomplish¬ 
ments in teaching and research, and (3) 
names and addresses of five references. 
Nominations should be submitted with the 
complete name, mailing address and tele¬ 
phone number of the individual nominated. 

Applications and nominations should be 
sent to Professor J. David Irwin, Department 
of Electrical Engineering, Auburn University, 
AL 36849-5201. Auburn University is an af¬ 
firmative action/equal opportunity em¬ 
ployer. Applications from minority and 
female candidates are encouraged. 


TECHNICAL UNIVERSITY OF 
NOVA SCOTIA 
School of Computer Science 

Applications are invited for a Research 
Associate/Post Doctoral position to par¬ 
ticipate in NSERC supported VLSI research. 

The successful applicant will supervise and 
participate in the programming of a VLSI 
design and modelling environment based on 
pictorial software principles, and will have 
the opportunity to participate in related 
research with the holders of the NSERC 
(Natural Sciences and Engineering Research 
Council of Canada) strategic research grant 
which supports this project. 

Candidates should have experience with 
VLSI CAD tools, hardware description 
languages, modelling/simulation, and a 
knowledge of high-level synthesis issues. 
A Ph.D. in computer science or electrical 
engineering with relevant publications or 
equivalent industrial experience is expected. 

The School of Computer Science at 
TUNS offers top-quality Computer Science 
bachelor, master’s and doctoral programs. 
The Halifax metropolitan area, with a 
population of approximately 300,000, is the 
cultural and business centre of Atlantic 
Canada and affords its residents a high quality 
of life. 

This is a term position with salary in the 
range $35,000 to $40,000, depending on 
qualifications and experience. In accordance 
with Canadian immigration requirements, 
priority will be given to Canadian citizens and 
permanent residents. Applications should be 
submitted to the Director, School of Com¬ 
puter Science, Technical University of Nova 
Scotia, P.O. Box 1000, Halifax, Nova 
Scotia, CANADA, B3J 2X4. 


UNIVERSITY OF UMeA, SWEDEN 
Professor of Computer Science 

Applications are invited for a new position 
as full professor in Computer Science (Data- 
logi in Swedish) at the Department of Com¬ 
puting Science. 

The department offers bachelor's, licen¬ 
tiate's and doctoral degrees in Computing 
Science with emphasis on Numerical An¬ 
alysis, Parallel Computing and Computer 
Science. Research is conducted in parallel 
and distributed computing, term rewriting, 
automated reasoning and deductive data¬ 
bases, cognitive science and human-compu¬ 
ter interaction. Al-philosophy. functional 
programming, numerical linear algebra and 
optimization. Facilities include an Intel 
iPSC/2 hypercube (64 nodes), ALLIANT 
FX/2816 (16 processors) with Visualization 
unit, SUN Workstations and personal com¬ 
puters (Macintosh, PC). 

Candidates should have a distinguished 
record of original research in Computer 
Science and proven teaching and leadership 
qualities. Salary is expected to range be¬ 
tween 300,060 and 400,000 SEK per an¬ 
num, depending on qualifications and ex¬ 
perience. The appointee is expected to 
conduct and supervise research and partici¬ 
pate in graduate teaching at the department. 

Applications should include a curriculum 
vitae, copies of degree certificates, a state¬ 
ment of previous research achievements and 
teaching merits, a list of publications, and 
reprints numbered according to the list, all in 
4 copies. Applicants should also indicate 
which publications that are of first hand 
relevance. 

Applications are to be directed to the 
Government of Sweden with reference 
number DNR 321-941-91. Notice, that all 
documents (including the application) are to 
be sent to Rektorsambetet, University of 
Umea, S-901 87 UMEA, SWEDEN. 

The closing date for applications is Sep¬ 
tember 16. 1991. 

For further details please contact Professor 
Sven Lindskog, Dean of the Faculty of 
Mathematics and Natural Sciences, Phone: 
+ 46-90165387, Professor Bo Kagstrom, 
Chairman of the Department of Computing 
Science, Phone:+46-90165419, Fax: 
+ 46-90166126, Email: bokg@cs.umu.se. 

University of Umea is a young university 
(25 years old) that lies at the mouth of the 
river Ume, equidistant (670 km) from both 
the capital Stockholm and Sweden's nor¬ 
thernmost town Kiruna. Today the campus 
has around 13,000 students and 3,000 
employees. The city of Umea and its sur¬ 
roundings offer surpassing opportunities for 
outdoor recreations and sports. For its size 
(over 90,000 inhabitants) Urned has a rich 
cultural life including Norrlandsoperan (The 
Opera of Norrland). 
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TRINITY COLLEGE 


UNIVERSITY OF UME&, SWEDEN 
Visiting Scientist Position in 
Computer Graphics and 
Scientific Visualization 

Um ei University is together with the 
Technical University of Luled; the Institute of 
Space Physics in Kiruna and the Industrial 
Development Center in SkellefteS, founder 
of Supercomputer Center North (SDCN). 
SDCN is one of two national centers for 
supercomputing. in Sweden and is con¬ 
nected to all Swedish universities through 
the Swedish University Network (SUNET). 
Thereby scientists have access to a six pro¬ 
cessor IBM 3090 VF/600J, placed at Norr- 
data in Skelleftea. 

Due to the partnership in SDCN a position 
as Visiting Scientist in Computer Graphics 
and Scientific Visualization is open for ap¬ 
plication. The position is placed at the 
department of Computing Science (see an¬ 
nouncement above for more information). 
Candidates are welcome to apply for a 3-24 
months stay. 

The field has a wide and interdisciplinary 
profile and candidates for the position can 
have different scientific profiles ranging from 
research in tools and methods for Computer 
Graphics and Visualization in Scientific 
Computing, to graphics computing and Visu¬ 
alization in Scientific Computing with an em¬ 
phasis on applications from biology, biotech¬ 
nology, chemistry, physics and medicine. At 
the university we have applications/possible 
applications in, for example, biotechnology- 
molecular biology, chemometrics, comput¬ 
ing science, environmental chemistry, en¬ 
vironmental ecology, geographical informa¬ 
tion systems, industrial design, medicine, 
physical chemistry, psychology, theoretical 
physics and space physics. 

Applicants interested to contribute to our 
serious efforts in developing the field of 
Scientific Visualization at the University of 
Umed should send their applications to Pro¬ 
fessor Bo KSgstrom, Chairman, Department 
of Computing Science, University of Umea, 
S-901 87 UMEA, SWEDEN. The applica¬ 
tion should include curriculum vitae, sum¬ 
mary of scientific and teaching merits, a list of 
publications and publications relevant for the 
position. 


SUNY AT BUFFALO 
Research Scientist 

Two positions for Research Scientists 
available. Requirements: M.S. in Computer 
Science, completion of all course work 
towards Ph.D. degree in Computer Science, 
3 years research experience on document 


ability to write research grant proposals; 
3 years familiarity with UNIX workstations, 
C-programming and LISP, familiarity with 
image processing software, such as HIPS. 
Annual salary of $30,000-$34,000. Appli¬ 
cations to CEDAR, 226 Bell Hall, SUNY 
Buffalo, NY 14260. EO/AA. 


RESEARCH SCIENTIST 

Design and creation of experimental pro¬ 
tocols and theoretical models of human per¬ 
formance; duties include specification and 
implementation of unique physiological in¬ 
strumentation and original control, acquisi¬ 
tion, and analysis software; integration of all 
components into a cohesive scientific para¬ 
digm. Requirements include Ph.D. in Com¬ 
puter Science or Biomedical Engineering; 
Strong background in basic research and 
conceptual models; computer hardware in¬ 
terface and control of external devices, signal 
processing (filtering, spectral and statistical 
analysis), graphical animation, statistical tests 
and distributions, and mathematical model¬ 
ing. Salary $40,000.00 40 hours/wk. Re¬ 
spond with two copies of resume to Job 
Order *1639, Mass. Dept, of Employment 
and Training, Special Programs Dept., 19 
Staniford Street, Boston, MA 02114. No ex¬ 
perience required. 


ARIZONA STATE UNIVERSITY 
Department of Computer Science 
and Engineering 
Research Scientist 

The tasks of the successful candidate will 
include the following: Design and develop 
software for applications in Distributed Ar¬ 
tificial Intelligence and Distributed Intelligent 
Simulations. Design and implement algo¬ 
rithms for distributed planning, control and 
problem solving. Design and integrate 
graphical user interfaces and intelligent front- 
ends for application software. Supervise 
graduate students and the operations of a 
research laboratory. Interact and communi¬ 
cate with external agencies and write pro¬ 
posals for research funding. The position will 
be available as of October 1, 1991 subject to 
the availability of funding. 

The candidate must have a Ph.D. in com¬ 
puter science with specialization in artificial 
intelligence. He/she must also have at least 
two years’ experience in computer networks 
and distributed computing (academic or in¬ 
dustrial) and at least two years research and 
development experience after the M.S. 
degree. The candidate must be able to pro¬ 
gram in Lisp, C, SIMSCRIPT, MODSIM, 
CSIM, Xlib, DECWindows and UIL, and be 
proficient in developing expert systems using 
shells such as CLIPS, GEST, and OPS-5. At 
least three years of experience with VMS 
and UNIX is also required. Minimum salary 
$42,000.00 per academic year. Salary will 
be commensurate with experience. Proof of 
authorization to work in U.S. is required, 
when hired. 

Please send a curriculum vitae and the 
names of three references to: 

Prof. Nicholas V. Findler 
Director, Artificial Intelligence Laboratory 
Department of Computer Science 
and Engineering 
Tempe, Arizona 85287-5406 
Internet: findler@enuxua.eas.asu.edu 
Deadline: Sept. 15, 1991. ASU is an 
EO/AA employer. . 


Trinity College, one of the few highly 
selective liberal arts colleges awarding 
degrees in engineering, seeks applicants for 
a tenure-track assistant professorship in 
Mechanical Engineering. Employment will 
start in the fall of 1992. Candidates must 
hold a Ph.D. in Mechanical Engineering with 
primary expertise in thermodynamics and 
heat transfer. A successful candidate will be 
committed to teaching engineering within a 
liberal arts setting and to offering courses for 
non-science majors on a regular basis. 

Trinity offers a standard curriculum in 
Mechanical Engineering and provides la¬ 
boratories for research and instruction. The 
department is located in a new Mathematics, 
Computing, and Engineering Center that 
houses laboratories for instruction and re¬ 
search in solid state electronics, integrated 
circuit design, solid mechanics, materials 
science, fluid mechanics, and electrophysio¬ 
logy. Computing resourses include Macin¬ 
tosh and PC-compatible microcomputers; 
SUN, Apollo, and DEC workstations; and 
VAX mini/mainframes. These computers 
are networked through an Ethernet LAN 
and connected worldwide to the Internet. 

Candidates must send a curriculum vita, a 
statement of teaching and research objec¬ 
tives, copies of published articles, and the 
names of three people willing to write letters 
of recommendation to Dr. David J. Ahlgren, 
Chair, Department of Engineering and 
Computer Science, Trinity College, Hart¬ 
ford, CT 06106. We especially seek applica¬ 
tions from women and members of minority 
groups. Applications will be accepted until 
January 10, 1992. Trinity College is an 
AA/EO employer. 


UNIVERSITY OF NOTRE DAME 
Faculty Positions 

The Department of Computer Science 
and Engineering at the University of Notre 
Dame invites applications for tenure track 
faculty positions at all ranks. Applicants 
should have a doctorate in Computer Sci¬ 
ence, Computer Engineering, Electrical 
Engineering, or a related field. Candidates in 
all research areas are invited to apply. How¬ 
ever, areas of particular interest within the 
Department are Parallel and Distributed 
Computing, Parallel Architectures, and 
VLSI. Applicants should have abilities and 
interests in teaching at the undergraduate 
and graduate levels, advising students, and 
conducting research. Rank and salary are 
negotiable. Interested persons should for¬ 
ward a complete resume, together with the 
names, addresses, and telephone numbers 
of at least three references, to: 

Dr. Steven C. Bass, Chairman 
Department of Computer Science 
and Engineering 
University of Notre Dame 
Notre Dame, IN 46556 
The University of Notre Dame is an Affir¬ 
mative Action/Equal Opportunity Employer. 
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UNIVERSITY OF KARLSRUHE 
Professor of Computer Science 

The University of Karlsruhe. Germany, is 
seeking candidates for the position of an 
Associate Professor of Computer Science 
(level "C3”) for the area of distributed 
systems and computer communications at its 
Institute of Telematics. Major focus areas are 
communication software, distributed appli¬ 
cations. high-speed network protocols, and 
specification, modeling, and verification of 
communication systems. The university of¬ 
fers a rich networking environment facili¬ 
tating the combination of theoretical and ex¬ 
perimental work. Applicants must have a 
Ph.D. degree in Computer Science and a 
record of distinguished research perfor¬ 
mance in some of the intended focus areas. 
They must also have a strong commitment to 
teaching, supported by previous experience. 
German language skills are not an absolute 
prerequisite. Applicants should send a 
resume and three references to: Dekan der 
Fakultaet fuer informatik. Kaiserstrasse 12. 
7500 Karlsruhe. Germany. 


U.S. MILITARY ACADEMY 

Visiting Professor in Computer Science, 
U.S. Military Academy. Applications are in¬ 
vited for AY 1992-1993 for appointment 
consideration under the provisions of the In¬ 
tergovernmental Personnel Act of 1979. 
Applicants must have Ph.D. possess strong 
commitment to undergraduate teaching, 
and currently hold the academic appoint¬ 
ment of Professor or Associate Professor. 
Duties include teaching in, and providing ad¬ 
vice on, the academy's computer science 
programs. Compensation is usually com¬ 
mensurate with that currently being re¬ 
ceived. Send resumes to Col. Daniel M. 
Litynski, Department of Electrical Engineer¬ 
ing and Computer Science, U.S. Military 
Academy. West Point. NY 10996. Applica¬ 
tions must be received by 1 October 1991. 
The U.S. Military is an affirmative action/ 
equal opportunity employer. 


WASHINGTON UNIVERSITY 

Washington University in St. Louis seeks 
qualified candidates for the position of Pro¬ 
fessor and Chair of the Department of Com¬ 
puter Science, with a desired starting date of 
July 1, 1991. We are interested in candi¬ 
dates with a strong research record, with a 
dedication to excellence in undergraduate 
and graduate education and with a demon¬ 
strated potential for administration and 
leadership. 

The Department has an excellent under¬ 
graduate program as well as a strong and ex¬ 
panding graduate program. The primary re¬ 
search concentrations are in distributed 
systems, advanced communication networks 
and intelligent computer systems with an 


emphasis on visualization as a tool in each 
case. The Department plans to continue 
building on these areas of strength as well as 
expanding into new areas. There are 15 
regular faculty in the Department and 85 
graduate students, as well as an excellent 
technical support staff and a large pool of af¬ 
filiate faculty. Departmental laboratory facili¬ 
ties are very good and include a visualization 
laboratory, a systems prototyping lab, a 
NCUBE parallel computer, a variety of com¬ 
pute servers and ubiquitous workstations. 

Washington University has a longstanding 
commitment to the principle that all can- 
diates should be afforded equal opportunity 
regardless of age, race, sex or physical 
disability. Candidates must send a curricu¬ 
lum vitae and a list of references to: Professor 
C.l. Byrnes, Search Committee for the Com¬ 
puter Science Chair, Campus Box 1040, 
Washington University, One Brookings Drive, 
St. Louis. MO 63130. 


D.E. SHAW & CO. 

Algorithmic Trading 

D.E. Shaw & Co. is a small (several dozen 
employees), highly capitalized (over $300 
million in partners' equity), extremely suc¬ 
cessful Wall Street firm specializing in quan¬ 
titative finance and computational trading. 
Computer scientists and system designers 
form the professional core of the firm, and 
not merely its support staff, and participate in 
its profits. Our technical staff includes both 
Ph.D.-level researchers recruited from Stan¬ 
ford, MIT, and other leading computer 
science departments and extraordinarily 
talented B.S.-and M.S.-level system de¬ 
signers and "superhackers". It is our practice 
to compensate unusually gifted individuals at 
a level exceeding that of the market. Appli¬ 
cants should send resumes to Esther Treitel, 
D.E. Shaw & Co.. 251 Park Avenue South. 
15th Floor. New York, NY 10010. 


CRIM 

Parallel Programming Researchers 

The Centre de recherche informatique de 
Montreal (CRIM) is a non-profit corporation 
focussing on excellence in research and 
development and on the transfer of informa¬ 
tion technologies and their applications. 

CRIM is seeking Parallel Programming 
Researchers for a joint industry university 
research project. The objective of this 
challenging research project is the develop¬ 
ment of a portable parallel programming en¬ 
vironment for current and future generations 
of Parallel Computers. 

RESPONSIBILITIES 

• To lead the R&D activities of a team of 
dynamic analysts including graduate stu¬ 
dents at the Ph.D. level in collaboration 
with well known researchers from Montreal 

• To oversee the development of "proof of 
concept' prototypes. 


QUALIFICATIONS 

• Ph.D. in related disciplines 

• Str< ng inter si n inn it i . u li 

• Leadership qualities 

• Experience in a large software develop¬ 
ment project. 

Industrial experience will be considered an 
asset. Interested candidates may apply by 
sending a resume before September 15, 
1991 to: 

Ms. Frances de Verteuil 
Centre de recherche informatique de 
Montreal 

3744. rue Jean Brillant. bureau 500 
Montreal. Quebec H3Y 1P1 (Canada) 
e-mail: de_verteuil@crim.ca 


COMPUTER SYSTEMS ANALYST 

Minimum 18 months experience with BS 
degree computer science or related field. 
Will be responsible for the logical and struc¬ 
tural development of software solutions to 
meet client's business needs using Digital 
Command Language. BASIC. COBOL. 
DEC. HMO. PPO. Will also correct program 
logic, preparation of documentation on 
systems, functional and technical design of 
systems and writing computer instructions. 
Salary $37,800 Year. Send Resume to A.R. 
JENSEN INFORMATION CONCEPTS. 
INC.. 17800 Castleton St.. Suite 650, City 
of Industry. California 91748. 
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BOOK REVIEWS 


Editor: Alan Kaminsky, Department of Information Technology, Rochester Institute of Technology, PO Box 9887, Rochester, NY 
14623-0887; (716) 475-5255; Internet ark@cs.rit.edu; Bitnet arkics@ritvax. 


Distributed Group Communication — the Amigo 
Information Model 

Hugh Smith, Julian Onions, and Steve Benford, eds. (Ellis Horwood Ltd., Chichester, England, 1989,188 pp., $49.95) 


In industry jargon, the term “group- 
ware” describes local area network 
software that helps groups of users 
work together more efficiently. It ex¬ 
tends the capabilities of electronic 
mail and shared file access to support 
such functions as group scheduling, 
news distribution, and conferencing. 
The Lotus product Notes serves as an 
example of groupware currently used 
in industry. 

Instead of groupware, this book 
uses the term group communication 
service, and it investigates how to 
base this service on Open Systems In¬ 
terconnection technologies. The book 
is actually a series of papers by differ¬ 
ent authors who collaborated on a re¬ 
search project called Amigo (Ad¬ 
vanced Messaging in Groups). The 
authors present an abstract data mod¬ 
el, an architecture, and some proto¬ 
typing for a group communication ser¬ 
vice. 

The introductory chapter briefly ex¬ 
amines current systems providing 
group communication support and 
finds them lacking in functionality, 
dependent on centralized resources, 
or based on nonstandardized services. 
The authors contend that group com¬ 
munication services must be based on 
OSI standards to adequately serve the 
needs of widely distributed groups. 
However, current OSI services do not 
provide the necessary group commu¬ 
nication support unless integrated by 
a higher layer. The remainder of the 
book proposes ideas for this OSI- 
based group communication service. 

The authors do not explain in con¬ 
vincing detail what is inadequate 
about the current OSI services. For 
the benefit of novices in the field, an 
appendix briefly outlines four services 
that were examined with group com¬ 
munication needs in mind: X.400 mes¬ 


sage handling, X.500 directory servic¬ 
es, File Transfer Access and Manage¬ 
ment (FTAM), and Document Filing 
and Retrieval (DFR). As a novice my¬ 
self, I found the appendix too brief 
and sketchy. For example, the section 
on X.400 did not discuss the PI and 
P2 peer protocols, which turn out to 
be important parts of the book’s pro¬ 
posed group communication architec¬ 
ture. 

My main criticism of the book is 
that the authors frequently assume 
knowledge by the reader or point to a 
reference instead of discussing a con¬ 
cept within the text. The book has 
many references throughout, and I 
found the ones I pursued helpful in 
providing background information. 
However, readers new to the field 
should be aware that the book may be 
difficult to read as a stand-alone text. 

The authors present an abstract 
data model of group communication 
that can be used to describe user re¬ 
quirements. As the subtitle indicates, 
this model and its implementation are 
the focal points of the book. The mod¬ 
el is based on the concept of informa¬ 
tion objects such as messages and doc¬ 
uments that are shared by 
communicating groups. No explicit 
mechanism is provided for modeling 
the dynamics, protocols, and process¬ 
es of human-to-human communica¬ 
tion. Rather, communication patterns 
are assumed to be implicit in the at¬ 
tributes that describe information ob¬ 
jects. 

Other researchers have taken ap¬ 
proaches to modeling group commu¬ 
nication that do focus on process. 
Many of these are described in a com¬ 
panion volume, Computer-Based 
Group Communication (U. Pankoke- 
Babatz, ed., Ellis Horwood, 1989), 


which resulted from a related Amigo 
research effort. 

The group communication architec¬ 
ture is composed of distribution, ar¬ 
chive, and coordination services. As 
the authors describe it, the coordina¬ 
tion service provides the “glue” be¬ 
tween other services and maps user 
requirements onto these services. The 
coordination service is given a one- 
page treatment due to the contention 
that it is application dependent and 
focuses on such higher level activities 
as knowledge-based information han¬ 
dling, which is outside the scope of 
the book. The architecture discussion 
would have had more substance if the 
coordination service had been more 
thoroughly detailed. 

Along with the abstract data model, 
the distribution and archive services 
are covered in greatest detail. The ar¬ 
chive service provides the internal 
representation of the data model. The 
authors found that neither the FT AM 
nor the DFR services provide the nec¬ 
essary multiuser distributed storage 
capabilities, so they propose their own 
storage service. The distribution ser¬ 
vice is based on X.400 message han¬ 
dling coordinated with X.500 directo- 


Books and more books 

Anyone interested in con¬ 
ducting book reviews for Com¬ 
puter should contact the book 
reviews editor at the above ad¬ 
dress. Please indicate the sub¬ 
ject area you would like to re¬ 
view. 

Recently published books are 
welcome for review. 
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ry services. The authors discuss what 
they see as needed extensions to the 
directory service standard. 

Some limited prototyping of the dis¬ 
tribution, archive, and supporting di¬ 
rectory services is discussed. This pro¬ 
totyping achieved some success but 
also revealed some problems to be ad¬ 
dressed by further study. 

A researcher or systems engineer 
with a background in OSI network ar¬ 
chitecture, electronic messaging, and 


office information systems will find 
the book worth reading. I believe it 
presents forward-looking research on 
OSI-based services, since almost no 
one has much experience implement¬ 
ing or using OSI standards. Only a 
few systems have implemented the 
X.400 standard for electronic messag¬ 
ing, and, as of the writing of the book, 
the X.500 directory services had not 
yet reached full standardization. 

To those who seek more back¬ 


ground on the subject, I recommend 
one of the book’s references: Proceed¬ 
ings of the IFIP TC 6/WG 6.5 Working 
Conference on Message-Handling Sys¬ 
tems (R. Speth, North Holland, New 
York, 1988, 463 pp.). However, this 
book certainly deserves to be read by 
anyone interested in current research 
on distributed group communication. 

Luanne Hendricks 

AT&T Bell Laboratories 


Real-Time System Design 

Shem-Tov Levi and Ashok K. Agrawala (McGraw-Hill, New York, 1990, 299 pp., $51.65) 


Some 15 books on real-time systems 
have been published within the last 
four years — a number unprecedent¬ 
ed for this field and uncommon for 
many other fields in computer science. 
This fact certainly points to the grow¬ 
ing significance real-time systems hold 
in contemporary societies. 

This book is the broadest in scope, 
combining system design aspects with 
operating system features. The au¬ 
thors were inspired to take this ap¬ 
proach because no book on real-time 
systems has actually considered time 
an inherent property of participating 
parties. The authors “... consider 
time to be an integral property of ev¬ 
ery entity in the system” because "... 
it is essential for the next generation 
of hard real-time systems to use time 
directly and explicitly.” 

The structure of the book is very 
clear. Part I describes timing proper¬ 
ties of real-time systems and a method 
for assigning them to objects. The use 
of the term object here differs, howev¬ 
er, from the common understanding 
implicit in object-oriented program¬ 
ming. I don’t feel the variance is justi¬ 
fied (even though the authors claim 
their term is more general). 

Part II, which should be headed 
“Developing Real-Time Applica¬ 
tions” rather than “Real-Time Appli¬ 
cations,” reviews some approaches to 
real-time systems design. The reviews, 
excluding a good chapter on Petri 
nets, are too short to give meaningful 
information (Design Approach for 
Real-Time Systems, State-Mate, 
weakest preconditions, real-time log¬ 
ic, and temporal logic receive a few 
pages each). The same is true for real¬ 
time language descriptions: Ada, Es- 


trel, and Real-Time Euclid are men¬ 
tioned on less than two pages apiece. 

Another drawback is that an impor¬ 
tant chapter on verification and valida¬ 
tion of real-time systems is totally 
based on an outdated — but very good 
— book edited by Bill Quirk ( Verifica¬ 
tion and Validation of Real-Time Sys¬ 
tems, Springer-Verlag, New York, 
1985). I suggest updating the material 
according to a book written by the 
same group of researchers (F. Redmill, 
Dependability of Critical Computer 
Systems, Vols. 1 and 2, Elsevier, Lon¬ 
don, 1989). 

Despite these shortcomings, this is 
the first book that presents concise de¬ 
scriptions of various, real-time-related, 
design methods collected into just a 
few chapters. 

The third part of the book results 
from the claim that the operating sys¬ 
tem is a primary component that must 
be taken into account in the design of a 
real-time system. Although this obser¬ 
vation is generally true, I would like to 
see a smoother transition from general 
real-time system design methodology 
to one that focuses attention on operat¬ 
ing system issues. 

This section presents a comprehen¬ 
sive discussion of two major functions 
of real-time operating systems — 
scheduling and resource allocation — 
followed by a much shorter and insuffi¬ 
cient treatment of network communi¬ 
cations. 

The last part about operating system 
implementation is probably the weak¬ 
est portion of the book. It contains 
very little useful information. On the 
other hand, it doesn’t really give 
enough information for a reviewer to 
fairly judge its contents. In future edi¬ 


tions, which I am sure this book will 
have, this part should be either 
dropped or significantly extended. It 
could even be extended to a separate 
book. 

Real-Time System Design has sev¬ 
eral other, less-significant weak 
points. First, naming Ada an asyn¬ 
chronous language is inappropriate, 
because one of its primary constructs 

— a rendezvous — is synchronous by 
its very nature. Next, the CSMA- 
based communication protocols are 
inherently nondeterministic and 
therefore not suitable for real-time 
applications, which must behave de¬ 
terministically. Furthermore, I was 
unable to find any definition of “job” 

— one of the most important concepts 
in the book. 

In spite of these faults, I stress this 
book’s usefulness for advanced aca¬ 
demic courses on real-time systems. It 
is also valuable for engineers or re¬ 
searchers working with these systems 
in their everyday lives. This part of 
the real-time systems community, 
which comes from a more practical 
background, is always searching inten¬ 
sively and impatiently for better theo¬ 
retical support. This book will certain¬ 
ly serve their needs to a large extent. 

Finally, the volume offers a unified 
treatment of design and operating sys¬ 
tem issues normally considered sepa¬ 
rately. In this respect, it is a move in 
the right direction, but an exhaustive 
treatment must include architectural 
issues as well. Such a book has yet to 
come. 

Janusz Zalewski 

Southwest Texas State University 
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Braunl’s Law 

Thomas Braunl, University of Stuttgart 

Parallel computer systems are quite 
popular these days. Expectations are 
high regarding program speedup by de¬ 
composing problems into subproblems. 
However, many well-known difficulties 
in parallel programming persist. 

These difficulties range from the 
complexity of parallel programming 
languages, to testing and debugging, 
to time-related errors, and to prob¬ 
lems with load balancing of parallel 
processors — the theoretical limits of 
which are known as Amdahl’s Law. 

From this law we learn, for exam¬ 
ple, that a parallel program with 10 
percent of pure sequential computa¬ 
tions (which cannot be parallelized) 
might not exceed a maximum speedup 
of factor 10 — this, regardless of the 
number of processors. 

In connection with this “law of na¬ 
ture” (and the fact that 10 percent of 
sequential computation seems quite 
realistic), I have been asked several 
times whether a massively parallel 
computer system with more than 
16,000 processors (such as the Con¬ 
nection Machine or MasPar) would 
make any sense. In contrast to Am¬ 
dahl’s Law for MIMD systems (multi¬ 
ple instruction, multiple data/asyn¬ 
chronous unrestricted parallelism), 
my answer is Braunl’s Law for SIMD 
systems (single instruction, multiple 
data/synchronous data parallelism). 

Amdahl's law. In simplified terms, this 
is Amdahl’s Law for MIMD systems: 

• T k is the execution time of a pro¬ 
gram with parallelization degree k 
on k processors. 

•/is the portion of the MIMD pro¬ 
gram (in percentages) that cannot 
be executed with parallelization 
degree k but only sequentially 
(that is, with degree 1). 

For a parallel computer system with 
A processors the following holds: 

T N =f* T, + (1 -/) * TJN 

Parallel speedup computes to: 

S N =T i IT N = NI(l +f* (A-1)) 

For example: 

• 1,000 processors are available, 

• the program has a maximum par¬ 
allelization degree of 1,000, 
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• 1 percent of the program cannot 
be parallelized and has to be exe¬ 
cuted sequentially (/= 0.01). 

Computing the speedup: 

Si ooo = 1,000/(1 + (1,000 - 1)/100) 

~ 91 

Only 10 percent of the peak perfor¬ 
mance is used — all for a tiny sequen¬ 
tial portion! 

The larger the sequential portion of 
a MIMD program, the more dramatic 
the loss in overall processor load and 
speedup, compared to a sequential 
computer system. The maximum 
speedup of a program may be comput¬ 
ed for each sequential portion — inde¬ 
pendent of the number of processors. 

lim S N (f) = A/( 1 +/* (A- 1)) = Ilf 


cuted with scalar commands (/= 

0 . 01 ). 

Computing the speedup: 

S1.000 = 0.1 + (1 - 0.01) * 1,000 - 990. 

Maximum speedup is almost reached! 

The larger the scalar portion of a 
SIMD program, the less the overall 
PE load. However, the decrease is lin¬ 
ear and not asymptotic as it is in Am¬ 
dahl’s Law. In addition, no limit for 
the maximum achievable speedup ex¬ 
ists; increasing the number of PEs re¬ 
sults in a speedup increase (provided 
the SIMD program has an appropriate 
parallelization degree). Actually, this 
is more a problem of scalability than 
speedup. 

Increasing the number of PEs by a 
factor of 10 results in 


This means that, for example, a 
MIMD program with a 10 percent se¬ 
quential portion could never exceed a 
speedup of 10 — again, no matter how 
many processors are used. 

Variation of the theme. Each SIMD 
program contains scalar and vector 
commands, while program execution 
(the flow of control) is identical to a 
sequential von Neumann system. If a 
single SIMD vector command with A 
processor elements (PEs) had to be 
performed on a sequential computer, 
A sequential commands would be 
needed. This fact recommends a back¬ 
ward inference from Amdahl’s Law. 

• T n is the execution time for a pro¬ 
gram with a maximum paralleliza¬ 
tion degree A on A PEs. 

•/is the portion of the SIMD pro¬ 
gram (in percentages) that has to 
be executed sequentially. 

Then, the following holds for the se¬ 
quential execution: 

T 1 =f*T N +(l-f) * N * T n 

Parallel speedup computes to: 

S N =T 1 /T N =f+(l-f) * A 

For example: 

• 1,000 processors are available, 

• the program has a maximum par¬ 
allelization degree of 1,000, 

• 1 percent of the program cannot 
be parallelized and has to be exe- 


S.o.ivC/) =/+(!-/) *10* A 

= 10 * (/+ (1 —f) * A) -9 */ 

= 10 * S N (f) - 9 * f 

=> 10 * S N (f) (for large A) 


Because of typical SIMD computa¬ 
tion, these programs usually have a 
much lower average PE load than 
MIMD programs. A single IF-THEN- 
ELSE selection with branches of 
equal size and probability reduces the 
average load to a mere 50 percent 
(because, for each branch, only one 
half of all PEs can be active). In most 
cases, however, this deficiency will be 
overcome simply by the enormous 
number of processors as compared to 
a MIMD system. 


Possible contradiction. Is there a 
contradiction between Braunl’s Law 
and Amdahl’s Law? 

The answer is no! Although Am¬ 
dahl’s Law, in principle, applies also to 
SIMD systems, you would have to use 
a different value for the sequential por¬ 
tion/in Amdahl’s Law, since a SIMD 
program with A PEs executes A basic 
operations with each command. 

We hid the fact that/ MIMD */ S!MD . 
Hence, it also becomes clear why 
speedup limits do not apply to SIMD 
systems: The sequential portion in 
Amdahl’s Law depends on the num¬ 
ber of SIMD processors. The more 
PEs participate in a SIMD command, 
the less becomes the sequential por¬ 
tion/in Amdahl’s Law. 
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CALL FOR PAPERS 

29TH ACM/IEEE 
DESIGN AUTOMATION 
CONFERENCE® 

ANAHEIM CONVENTION CENTER • JUNE 8 -12,1992 



DAC is the premier conference devoted solely to the field of Design 
Automation. All aspects of the use of computers as aids to the 
design process, from conceptual design through to manufacturing, 
are included. Four session types are included: regular paper ses¬ 
sions, short paper sessions, panels, and tutorials. 


REQUIREMENTS FOR SUBMISSION 
OF PAPERS 


Authors should submit their papers to the Program Chair no later 
than October 25,1991. Each submission should include one cover 
page and eight stapled copies of the complete manuscript. 

The one cover page should include: 

•Name, affiliation, and complete address for each author 
•A designated contact person including fax (if available) and 
telephone number 

•A designated presenter, should the paper be accepted 
•The following signed statement: “All appropriate organiza¬ 
tional approvals for the publication of this paper have been 
obtained. If accepted, the author(s) will prepare the final 
manuscript in time for inclusion in the Conference pro¬ 
ceedings and will present the paper at the Conference.” 

The eight copies of the complete manuscript should each include: 
• Title of paper, 60 word abstract indicating significance of 
contribution, and a list of topic numbers, ordered by 
relevancy, most closely matching the content of the paper. 

To permit a blind review, do not include name(s) or 
affiliation(s) of the author(s) on the manuscript. 

•The complete text of the paper in English, including all 
illustrations and references, not exceeding 5000 words. 
Overly long papers will not be considered. The papers will 
be reviewed as finished papers. Preliminary submissions 
will be at a disadvantage. 

Notice of acceptance will be mailed to the contact person by 
February 7,1992. Authors of accepted papers must sign a copyright 
release form. 


PROGRAM CHAIR 


MP Associates, Inc. 

ATTN: Bryan Preas 

Program Chair, 29th DAC 

7490 Clubhouse Rd., Suite 102 

Boulder, Colorado, 80301 

For information call: (303) 530-4333 
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TOPICS OF INTEREST 


Authors are invited to submit original technical papers describing 
recent and novel research or engineering developments in all areas 
of design automation. Topics include, but are not limited to: 

1 Electrical Simulation 

2 Discrete Simulation 
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1.3 Timing Verification 

2.1 Test Validation and T 

2.2 Test Pattern Generatic 

2.3 Formal Methods for Desi 

3.1 Floorplanning and Placer 

3.2 Global and Detailed Routing 

3.3 Physical Module Generation 

3.4 Symbolic Layout and Compact! 

3.5 Complete Layout Systems 

3.6 Layout Verification (DRC, ER( 

4.1 Logic Synthesis and Optimizati 

4.2 Register-Level Synthesis and C 

4.3 Behavioral Synthesis and Syste 

5.1 Behavioral and Hardware Desc 

5.2 Design Systems and Databases 

6.1 DA for IC Fabrication 

6.2 Computer Aids for Manufacturi 

7.1 DA for Analog Circuits 

7.2 High Speed Systems and Micro 

7.3 DA for Electronic Packaging 

7.4 Technology CAD 

8.1 Human Factors in DA 

8.2 Frameworks in DA 

8.3 Software Engineering in DA 

9.1 Complete DA Systems 

9.2 User Experience with DA Systf 

9.3 Electronic Design Using DA 


PANELS, TUTORIALS, 
SPECIAL TOPIC SESSIONS 


Proposals for topics of Panels, Tutorial Sessions, and Full-Day 
Tutorials should be submitted to the Program Chair no later than 
October 25, 1991. Each proposal should not exceed two pages in 
length and should include a description of the topic, structure of the 
session or tutorial, and a list of participants. Contact should be made 
with all participants in advance. 


Special Topic Sessions rr 


describe the theme of the session. These proposal: 
be submitted by October 25, 1991. 
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Designing against the clock? Then try our Block, 



Hypersignal-Windows™ Block Diagram 

Advanced Simulation Software under Windows 3.0 


• Data Flow Driven 

• Multi-Rate Applications including 
decimation, interpolation, etc. 

• Open Software Architecture 

• New Blocks created using standard C 

• Supports Dynamic Data Exchange 
(DDE) interface 


• Compatible with Hypersignal-Workstation 
and other Hypersignal-Windows software 
applications 

• Blocks can make use of DSP plug-in boards 
for algorithm acceleration 

• Flexible interface to allow virtually every 
algorithm application from classical telecom 
applications to Digital Image Processing 


For more information, including VHS 
Demo Tape Request Form, contact: 

Hyperception, Inc. 

= = - £ — — 9550 Skillman LB 125 

phone (214) 343-8525 
fax (214) 343-2457 

International Representatives: 


GERMANY - Electronic Tools, phone: (02102) 841013, TLX 1631 + BTX 02102841013 1 + ,fax: (02102) 841000 * UK, IRELAND - Loughborough Sound Images, 
LTD., phone: (0509) 231843, TLX 341409 LUFBRA G. fax: (0509) 262433 * FINLAND - ITT, phone: (90) 739 100, TLX 121450 MultiKomponent, fax: (90) 712 
414 * FRANCE - BORES Signal Processing, phone: CC44 (0483) 740138, fax: (0483) 740136 * DENMARK - Assentoft Electronics, phone: (06) 16 29 26, fax: (86) 
16 20 12 * ISRAEL - IES Ltd., phone: (03) 7510927 * TAIWAN, ROC - EXARTECH International Corp., phone: 5372201-3, fax: (02) 5422689, TLX:26173 , 

EXARTECH 
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